Countly Server API

Name: Countly Server API
Brand: Countly Server API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentAnalyticsProduct AnalyticsapiKey19 EndpointsREST

For 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.

Install Jentic One Beta

Connect the Countly Server API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Countly Server API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Countly Server API.

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

GET STARTED

Start building with Countly Server API

Explore with Jentic

View OpenAPI Document

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.

Use Cases

Patterns agents use Countly Server API for, with concrete tasks.

★ 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.

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.

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.

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.

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

19 endpoints — jentic publishes the only available openapi specification for countly server api, keeping it validated and agent-ready.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Countly api_key values are stored encrypted in the Jentic MAXsystem vault. Agents receive a scoped session token per call, so the raw key never enters prompts or logs even though Countly accepts it as a query parameter.

Intent-based discovery

Agents search Jentic with intents like 'get user analytics from Countly' and Jentic returns the matching /o operation along with its parameter schema, so the agent calls the right endpoint without reading the spec.

Time to first call

Direct integration with Countly: 1-2 days to handle the api_key query parameter, /i versus /o routing, and JSON response shapes. Through Jentic: under 1 hour to search, load, and execute.

FAQs

Specific to using Countly Server API through Jentic.

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 at https://app.jentic.com/sign-up.

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 the encrypted MAXsystem vault 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.