REST API for your integrations
Your data team wants programmatic access to dashboards, reports, and metrics. clariBI ships a full REST API gated by per-key authentication, per-key rate limits, and a complete audit trail.
"id": "d_7f3a",
"name": "Q2 Revenue",
"updated_at": "2026-04-06T09:14:22Z",
"widgets": [
{ "id": "w_1", "type": "kpi",
"value": 680420, "target": 1000000 },
{ "id": "w_2", "type": "line_chart",
"series": [...] }
]
}
BI tools that don't expose an API are black boxes
Data teams want to pull metrics into other systems, trigger dashboards from CI, and embed insights in internal tools. Most BI tools either don't have an API, or hide it behind an Enterprise-only wall.
clariBI ships a first-class REST API on Professional and Enterprise. No special contract, no sales call, no "we'll get back to you."
No API at all
Some BI tools literally don't expose data programmatically. Your only option is to manually export CSVs, which is a guaranteed dead-end for automation.
Enterprise-only API tiers
"Sure, we have an API. It's $50k/year, minimum commit 3 years, and you need to talk to sales." No thanks.
One global rate limit
Your CI pipeline eats the shared rate limit and suddenly the dashboards nobody touched all week are throttled. Per-org limits are worse than no limits.
Keys stored in plaintext
A surprising number of tools still store API keys unhashed. One DB breach and every integration key is exposed.
How the clariBI API works
JSON, HTTPS, API keys. Nothing exotic. Works the way you expect a REST API to work.
REST endpoints for everything
Dashboards, reports, data sources, usage metrics, goals, and user management - all available as JSON over HTTPS. Authenticated by API key via the standard Authorization: Bearer header.
OpenAPI spec available in the developer portal so you can auto-generate client libraries in any language.
- ✓ Versioned at
/v1/- breaking changes bumped - ✓ Standard HTTP status codes and error envelopes
- ✓ Pagination with cursor-based continuation
Per-key access control
Generate multiple API keys, each with its own scope and its own rate limit. Use one key for production, another for staging, another for your CI pipeline. Revoke any one without affecting the others.
Each key inherits the role of the user who created it, so a Viewer-scoped key can't accidentally mutate data even if the calling code tries.
- ✓ Multiple keys per user or organization
- ✓ Revoke a single compromised key without rotation chaos
- ✓ Optional IP allowlists on Enterprise
Per-tier rate limits
Professional and Enterprise have different rate ceilings. Throttling is enforced per key, not per organization, so your automated CI pipeline can't starve your dashboards of requests.
Every response includes X-RateLimit-Remaining and X-RateLimit-Reset headers so you always know your headroom before you hit the wall.
- ✓ Sliding-window limiting, not hard minute buckets
- ✓ Standard rate-limit headers on every response
- ✓ 429 responses include a
Retry-Afterhint
Encrypted storage, audit trail, developer portal
Keys are hashed at rest. Even a database breach can't recover the original token. A short prefix is kept unhashed so you can identify keys in the audit log without exposing the secret.
The developer portal lets you create, list, revoke, and inspect keys, view usage per key, read the API reference, and see your rate-limit headroom in real time.
- ✓ Every API call logged with caller, endpoint, outcome
- ✓ In-portal Swagger/OpenAPI reference
- ✓ Per-key usage graphs and alerts
Example requests
# List all dashboards curl https://api.claribi.com/v1/dashboards \ -H "Authorization: Bearer $CLARIBI_KEY" # Response { "data": [ { "id": "d_7f3a", "name": "Q2 Revenue" }, { "id": "d_8b12", "name": "Marketing Funnel" } ], "next_cursor": null }
# Trigger a report run curl -X POST https://api.claribi.com/v1/reports/r_42/run \ -H "Authorization: Bearer $CLARIBI_KEY" \ -H "Content-Type: application/json" \ -d '{"format": "pdf"}' # Response { "run_id": "run_9c2e", "status": "queued", "estimated_ready_at": "2026-04-06T09:15:30Z" }
Built for data and platform engineers
Who need clariBI to talk to everything else in their stack.
Data teams piping metrics elsewhere
Pull clariBI metrics into your data warehouse, internal portal, or downstream reporting tool. The API becomes the glue between clariBI and the rest of your data stack.
Works as a source for reverse ETL pipelines too.
CI pipelines snapshotting dashboards
Every deploy, trigger a snapshot of your core KPIs. Attach it to the PR, the release note, or the Slack announcement. A dedicated CI key with its own rate limit makes this safe.
Your release history includes the actual business state at deploy time.
Backend automations on usage thresholds
Poll the usage endpoint from your backend, and when a customer crosses a threshold, trigger an in-app notification, an upsell email, or a Slack alert to your CS team. Low-effort, high-leverage.
Turn BI metrics into operational triggers.
Embedding clariBI in internal tools
Fetch a widget's data via the API and render it natively inside your own internal admin tools. Or use public sharing for iframe embeds when raw data isn't needed.
clariBI becomes the data layer for your operator UIs.
Secure by design, governed by RBAC
API keys aren't a bypass. Every call runs through the same permission check as the user who owns the key.
Audit & Security
Every API call is in the audit log with key prefix, endpoint, and outcome.
Granular RBAC
API keys inherit the role of their owner - no way to escalate privileges.
Data Integrations
Pair the API with native data source connectors for a full data pipeline.
REST API access is available on Professional ($199/mo) and Enterprise ($999/mo).
More API capabilities
The details developers actually care about when they're picking a BI tool to build on.
Cursor-based pagination
Stable pagination on long lists. No "offset moved" bugs when new items are inserted. next_cursor in every list response.
Request IDs in every response
Every response carries a unique request ID. Paste it into a support ticket and we can trace the request end-to-end in our logs.
OpenAPI / Swagger reference
Full OpenAPI 3 spec available in the developer portal. Auto-generate client libraries in TypeScript, Python, Go, or any language with an OpenAPI generator.
Key usage analytics
Per-key usage graphs in the developer portal. See which key is hitting the rate limit, which endpoints are most used, and which keys are stale and should be revoked.
IP allowlists (Enterprise)
Lock a key to specific source IPs or CIDR ranges. Even if the key leaks, requests from unexpected networks are rejected.
Example requests in every doc page
Every endpoint has copy-paste curl, Python, and JavaScript examples. Go from "reading the docs" to "first successful request" in minutes.
Under the hood
The API is a thin layer over the same service code that powers the Vue.js frontend. There's no separate "API data path" that can drift from the UI - if a dashboard works in the app, it works via the API.
API keys are hashed at rest using a salted one-way function. We keep a short unhashed prefix so audit logs can identify a key without exposing the secret. Revocation is instant: the hashed record is marked inactive and subsequent requests return 401.
Rate limiting runs in a sliding-window counter per key. The limiter is in-process and backed by Redis, so it's fast and consistent across the cluster. Standard rate-limit headers are returned on every response.
Hashed key storage
Keys are hashed on creation. The plaintext is shown once in the portal and never again. A short prefix is kept unhashed for audit log identification.
Sliding-window rate limiting
Redis-backed counter per key. Consistent across the cluster. Standard X-RateLimit-* headers on every response.
Shared code path with the UI
API and frontend share the same service layer. No drift between "what the UI shows" and "what the API returns."
Build on clariBI data.
Generate your first API key, fire your first curl, ship your first integration. Free trial - no credit card.
Getting started with the API
From "we need programmatic access" to "first successful request" in 10 minutes.
Generate an API key
Open the developer portal in Settings, click "Create API key," and give it a descriptive name ("production-etl" or "ci-snapshot-bot"). The plaintext key is shown once. Copy it and store it somewhere safe.
Read the OpenAPI reference
The in-portal API reference lists every endpoint with parameters, example requests, and response schemas. Find the endpoint you need, copy the example, and adapt it.
Fire your first request
Paste the example curl into a terminal, swap the $CLARIBI_KEY placeholder for your real key, and run it. A 200 response with JSON is your success signal.
Wire it into your integration
Move the key from your shell into your secret manager, generate a typed client from the OpenAPI spec if you want one, and ship your integration. Per-key usage analytics in the portal show you rate-limit headroom and error rates.
How we think about APIs
The principles behind the clariBI REST API.
The API is a product, not an afterthought
Every feature exposed in the UI is exposed in the API, with consistent naming, consistent error formats, and consistent pagination. Developers shouldn't have to reverse-engineer the frontend to figure out what's possible.
Keys hashed, never stored in plaintext
An API key is a bearer token, which means anyone holding it can act as the owner. We treat keys with the same care as passwords: hashed on creation, shown once in the portal, never recoverable. A database breach can't expose live keys.
Per-key rate limits, not per-org
One misbehaving CI job should never take down your production dashboards. Each API key has its own rate-limit bucket, so you can isolate workloads without opening support tickets.
Boring, predictable, versioned
We don't ship a new experimental API format every quarter. v1 is stable. When breaking changes come, they ship as v2 and v1 keeps working. Boring is a feature.
API calls respect RBAC
An API key can't do anything the human who created it can't do. If you give a key to a Viewer, it can only read. Privilege escalation through the API is simply not possible by design.
Every call is in the audit log
API calls land in the same audit trail as human logins. You can filter by key, by endpoint, by outcome, and spot anomalies the same way you spot them on the UI side.
API access across plans
Full API, or no API - no secret middle tier.
| Capability | Starter | Professional | Enterprise |
|---|---|---|---|
| REST API access | No | Yes | Yes |
| Multiple API keys | No | Yes | Yes |
| Developer portal | No | Yes | Yes |
| OpenAPI reference | No | Yes | Yes |
| Per-key rate limits | No | Yes | Yes |
| Rate limit ceiling | - | Standard | Higher, negotiable |
| IP allowlists | No | No | Yes |
| Custom SLA | No | No | Yes |
See pricing for full plan details.
API & Developer FAQ
Common questions about the clariBI REST API.
Where are the API docs?
In the developer portal inside the clariBI app. Log in, go to Settings → Developer → API Keys, and you'll find the interactive OpenAPI/Swagger reference plus the ReDoc version for deeper reading.
How do I rotate a key?
Generate a new key, deploy it to your integration, confirm it's working, then revoke the old one from the developer portal. Because multiple keys per user are supported, rotation is zero-downtime.
What's the rate limit on Professional vs Enterprise?
Professional has a generous per-key limit suited to typical integration and CI workloads. Enterprise has a substantially higher ceiling plus the ability to negotiate custom limits. Exact numbers are documented in the developer portal so they stay current with your account.
Can I use the API with the trial?
Full API access is available on Professional and Enterprise. During the 14-day trial you can evaluate the developer portal and the OpenAPI reference; upgrade to Professional to start making authenticated calls.
Does the API support webhooks?
Outbound webhooks for key events (data source changes, goal alerts, report runs) are on the roadmap. Today the pattern is polling the API from your backend on a schedule - the rate limits comfortably accommodate that.
Are there official client libraries?
We ship an OpenAPI spec and recommend generating a typed client from it in whatever language you use. Most language ecosystems have good OpenAPI generators (openapi-generator, openapi-typescript, etc.). This approach scales better than maintaining hand-written SDKs in every language.
Can I test against a staging environment?
The recommended pattern is to use a separate clariBI organization for staging. Generate dedicated API keys scoped to that org, and your production keys never touch your test environment. Enterprise customers can request a dedicated sandbox org.
What's the API uptime target?
The API shares uptime with the main application. Professional customers get best-effort uptime; Enterprise customers can sign a contractual SLA with specific guarantees. Status and incident history are published at the clariBI status page.
How are API errors structured?
Standard HTTP status codes (4xx for client errors, 5xx for server errors) with a JSON error envelope: {"error": {"code": "...", "message": "...", "request_id": "..."}}. Every error includes a request ID you can reference in a support ticket.