Skip to main content

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-After hint

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.

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.

1

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.

2

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.

3

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.

4

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 accessNoYesYes
Multiple API keysNoYesYes
Developer portalNoYesYes
OpenAPI referenceNoYesYes
Per-key rate limitsNoYesYes
Rate limit ceiling - StandardHigher, negotiable
IP allowlistsNoNoYes
Custom SLANoNoYes

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.