Public Endpoints for Restricted (Closed) Deployments

When deploying Countly in a restricted environment, you may want to keep your dashboard and internal APIs private, exposing only the endpoints required for external communication. This guide outlines which endpoints must be publicly accessible, which service handles each endpoint, and how to configure your network allowlists accordingly.

Overview

Countly consists of two main services:

• API: Handles event ingestion, SDK configuration, and widget data.

• Frontend: Serves static assets, Web SDK, widgets UI, images, and tracking pixels.

Public Endpoints by Feature

Note: Unless otherwise specified, most endpoints support both GET and POST methods. Allow both methods in your firewall or proxy configuration for maximum compatibility.

1. Event Collection (SDK Ingestion)

Service: API
Required if: Applications or websites send analytics data.

2. Remote Config & A/B Testing

Service: API
Required if: SDKs fetch configuration or experiment variants.

3. Heatmaps

Service:

• Data: API
• Rendering assets: Frontend

4. Surveys, NPS, and Feedback Widgets

Widget Data: API
UI & Static Assets: Frontend

5. In-App Messages / Content Blocks

Service: Frontend
Required if: Using content blocks or in-app messaging delivered from the server.

6. Web SDK Hosting

Service: Frontend
Required if: The Web SDK is loaded from your Countly server.

7. Tracking Pixel

Service: Frontend
Required if: Using email or lightweight tracking.

8. Attribution Short Links

Service: Frontend
Required if: Using campaign redirects.

9. Email Report Assets

Service: Frontend
Required if: Email reports include externally hosted images.

Example: NGINX Allowlist

Route requests to the correct service and block everything else.

upstream api {
    server countly-api:3001;
}
upstream frontend {
    server countly-frontend:3000;
}
server {
    listen 443 ssl;
    server_name analytics.example.com;

    # Default: deny everything
    location / { return 404; }

    # --- API endpoints ---
    location = /i { proxy_pass http://api; }
    location = /i/bulk { proxy_pass http://api; }
    location ~ ^/i/campaign/click/ { proxy_pass http://api; }
    location = /o/sdk { proxy_pass http://api; }
    location = /o/actions { proxy_pass http://api; }
    location = /o/feedback/multiple-widgets-by-id { proxy_pass http://api; }
    location = /o/feedback/widget { proxy_pass http://api; }
    location = /o/surveys/survey/widget { proxy_pass http://api; }
    location = /o/surveys/nps/widget { proxy_pass http://api; }

    # --- Frontend endpoints ---
    location = /pixel.png { proxy_pass http://frontend; }
    location = /sdk/web/countly.min.js { proxy_pass http://frontend; }
    location ~ ^/views/ { proxy_pass http://frontend; }
    location ~ ^/feedback { proxy_pass http://frontend; }
    location ~ ^/surveys/ { proxy_pass http://frontend; }
    location ~ ^/star-rating/ { proxy_pass http://frontend; }
    location ~ ^/stylesheets/font-awesome/ { proxy_pass http://frontend; }
    location ~ ^/stylesheets/ionicons/ { proxy_pass http://frontend; }
    location ~ ^/fonts/ { proxy_pass http://frontend; }
    location ~ ^/_external/content/ { proxy_pass http://frontend; }
    location ~ ^/at/ { proxy_pass http://frontend; }
    location ~ ^/campaign/ { proxy_pass http://frontend; }
    location ~ ^/images/ { proxy_pass http://frontend; }
    location ~ ^/appimages/ { proxy_pass http://frontend; }
    location ~ ^/dashboards/images/screenshots/ { proxy_pass http://frontend; }
}

Kubernetes Ingress (Concept)

Expose only required paths and route them to the appropriate service:

If you need further assistance configuring your deployment, please contact Countly Support.