canonical: https://jentic.com/apis/count.ly/countly

# Countly Server API

Jentic publishes the only available OpenAPI specification for Countly Server API, keeping it validated and agent-ready. The Countly Server API exposes the open-source Countly analytics platform's REST surface across 19 endpoints split into ingestion (/i) and read (/o) routes, covering session and user analytics, feedback widgets, dashboards, alerts, groups, tasks, and database exports. Authentication is via an api_key query parameter tied to a Countly user. Suitable for self-hosted analytics teams that want to push events programmatically, build custom dashboards, or extract raw analytics data for downstream warehousing.

## For AI agents

Read product analytics, manage dashboards and feedback widgets, create alerts, and export raw data from a self-hosted Countly server. Designed for teams running Countly on their own infrastructure.

## Scope

Does not handle marketing automation, A/B testing infrastructure, or paid ad analytics - use for self-hosted product and session analytics only.

## Capabilities

- Pull session and user analytics over arbitrary time ranges
- List, create, and delete dashboards in a Countly server
- Create feedback widgets and read collected feedback responses
- Configure metric-based alerts and enumerate existing ones
- Export raw database snapshots for warehousing or backup
- Inspect server health, overall system status, and running tasks
- Identify user flows and slipping-away cohorts for retention analysis

## Use cases

### Self-Hosted Product Analytics Reporting

Pull session and user analytics out of a self-hosted Countly server into a data warehouse, BI tool, or weekly summary email. The /o endpoints return JSON for sessions, users, flows, and slipping-away cohorts so an automation can refresh internal dashboards without giving every analyst direct Countly access. Useful for teams that prefer centralised reporting on top of an open-source analytics stack.

Example prompt: Call GET `/o/analytics/sessions` and GET `/o/analytics/users` for the last 7 days, then write the JSON results to a warehouse staging table

### Feedback Widget Automation

Programmatically create and manage Countly feedback widgets and pull collected responses for triage. Widgets are created via GET `/i/feedback/widgets/create` and responses are read via GET `/o/feedback/data`, so a workflow can spin up a survey, monitor responses, and route negative feedback to a support queue without anyone logging into the Countly UI.

Example prompt: Create a feedback widget via GET `/i/feedback/widgets/create`, then poll GET `/o/feedback/data` hourly and post any negative responses to a Slack channel

### Alerting on Analytics Anomalies

Configure Countly alerts that fire when active users, crashes, or other metrics breach a threshold, and manage them in code instead of through the UI. The API exposes GET `/i/alert/save` for create/update and GET `/o/alert/list` to enumerate existing alerts. Useful for teams that version-control alert definitions alongside infrastructure.

Example prompt: Read a YAML file of desired alerts, diff against GET `/o/alert/list`, and call GET `/i/alert/save` for any alerts that are missing or have changed

### AI Agent Analytics Q&A

Let an AI agent answer product questions like 'how many sessions yesterday' or 'who is slipping away' by calling Countly through Jentic. The agent searches Jentic for the right /o operation, supplies the query parameters, and the api_key stays in the encrypted vault. No need to embed the Countly API key in the agent's prompt or codebase.

Example prompt: Use Jentic to search 'get session analytics from Countly', load the schema for GET `/o/analytics/sessions`, and execute it for the last 24 hours

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/o/analytics/sessions` | Get session analytics |
| GET | `/o/analytics/users` | Get user analytics |
| GET | `/o/feedback/data` | Get feedback responses |
| GET | `/i/feedback/widgets/create` | Create a feedback widget |
| GET | `/o/dashboards/all` | List all dashboards |
| GET | `/i/alert/save` | Create or update an alert |
| GET | `/o/system/healthcheck` | System health check |
| GET | `/o/export/db` | Export database data |

## Key resources

- **Analytics** — Read sessions, users, flows, and slipping-away cohorts via /o endpoints
- **Feedback** — Create widgets and read collected feedback responses
- **Dashboards** — List, create, and delete dashboards
- **Alerts** — Create, update, and list metric-based alerts
- **Groups** — List and create user groups
- **System** — Inspect overall server status and run health checks
- **Export** — Export raw database data and run task lists

## Why Jentic

- **Setup:** Wiring the Countly Server API by hand means handling its api_key query-parameter auth and pointing every call at your own self-hosted Countly host. Through Jentic you install once, import the Countly Server API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Countly reads and writes use fixed operation paths like `/o/analytics/sessions` and `/i/alert/save` with no resource id in the URL, so scope by operation: limit the agent to the operations it needs, such as reading session analytics or a dashboard. You choose the operations it may call, so state-changing ones like saving an alert or exporting the database are not included unless you add them.
- **Credential handling:** Your Countly API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'read session analytics' or 'get feedback data', and Jentic returns the matching Countly operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Mixpanel API** — Hosted product analytics with deep funnel and retention reporting
- **Amplitude API** — Hosted product analytics focused on behavioural cohorts and retention
- **PostHog API** — Open-source product analytics with session replay and feature flags
- **Segment API** — Customer data pipeline that can route events into Countly

## FAQ

### Why is there no official OpenAPI spec for Countly Server API?

Countly does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Countly Server API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Countly Server API use?

The Countly Server API uses an API key passed as the `api_key` query parameter on every request. The key is tied to a Countly user. When called through Jentic, the key is stored in your encrypted Jentic One instance and the agent receives a scoped session token rather than the raw key.

### Can I extract raw analytics data from Countly via the API?

Yes. GET `/o/export/db` exports raw database data, and the `/o/analytics/sessions` and `/o/analytics/users` endpoints return structured JSON for sessions and users. Combine them to populate a warehouse staging table or a custom BI dashboard.

### What are the rate limits for the Countly Server API?

Because Countly is self-hosted, rate limits are governed by the deployment's own MongoDB and Node.js capacity rather than a published quota. For shared servers, keep concurrent /o calls to a small handful and prefer the /i ingestion endpoints for bulk event submission.

### How do I create a dashboard alert in Countly through Jentic?

Search Jentic for 'create a Countly alert', load the schema for GET `/i/alert/save`, and execute it with the alert's metric, threshold, and target email. Jentic handles the api_key credential transparently.

### Does the Countly Server API support webhooks?

The current spec does not expose webhook subscription endpoints. To react to analytics changes, configure alerts via GET `/i/alert/save` or poll `/o/analytics` endpoints on a schedule.

### Can I limit what my agent is allowed to do with the Countly Server API?

Yes. Because you run Jentic One yourself, your own rules decide which Countly operations and credentials the agent may use. Since Countly operations are fixed paths with no resource id in the URL, you scope by operation: allow read-only calls like GET `/o/analytics/sessions` and GET `/o/analytics/users` while withholding state-changing ones such as GET `/i/alert/save` or GET `/o/export/db.` Only the operations you grant are callable, and the API key stays with your instance rather than the agent.