Skip to main content
Use these endpoints to answer three questions about your account: what you spent credits on, which requests made up that spend, and which requests failed and why. They read the same record the Usage page of your dashboard shows.
These endpoints are free. Their responses carry no X-Credits-Used header. The four share one limit of 60 requests per minute per API key.

Endpoints

Authenticate with your API key in the Authorization header and send x-api-version: 2025-11-01. Every row is scoped to your team. No parameter reads another team’s usage. A request usually shows up in these endpoints within about 10 seconds of its response. The usage endpoints do not record your calls to them. The one exception is a call refused with a 429, which shows up like any other rate-limited request.

The time window

Every endpoint takes the same window: With no window, you get the last 7 whole days including today.

Filters

All filters are optional and combine with AND. List filters take a repeated parameter or one comma-separated value, so endpoints=/person/search,/person/enrich and endpoints=/person/search&endpoints=/person/enrich mean the same thing.

Charge components

Every charge is split into lines. Each line names what it charged in two fields:
  • component is a stable id such as person.business_email. It does not change. Build reports, alerts, and dashboards on it.
  • label is display text such as Business email. It can be reworded at any time, so show it to people but never match on it.
An event’s lines add up to its credits_used, which is the same number the original response returned in its X-Credits-Used header. Lines charged at 0 credits are kept, so the sum always matches. These are the component ids in use today: Some charges are priced per field or filter, and their ids follow a pattern instead of a fixed list: <entity> is person or company. <product> is the event’s product. <product>.request is a flat charge for the whole request, and <product>.other is a charge that does not have its own id yet. New ids are added to this page as they ship, and an id that exists never changes.

Summaries

GET /account/usage/summary adds your usage up. Pass group_by with any of day, product, endpoint, component, api_key_id, client_surface, client_platform, and status_class. Leave it out for one total row.
  • Grouping by day returns the time column as bucket_start. bucket=1d (the default) gives dates, and bucket=1h gives hourly timestamps.
  • Grouping by component returns component and label, and swaps errors and results for quantity, the units charged.
  • client_platform is the tool or runtime that made the call. See Client platforms below.
  • api_key_id is 0 for usage not tied to an API key, such as data exports, watch runs, and requests refused with a 429.
  • Rows are sorted by bucket_start when you group by day, then by credits, highest first.
With bucket=1d and a window of whole UTC days, which includes the default window, some shapes are rejected with a 400 telling you to retry with bucket=1h:
  • component combines only with day and product, and filters only by products.
  • The status and error_type filters are not available.
A window that starts or ends mid-day, bucket=1h, or any grouping that includes client_platform accepts every combination.

Client platforms

client_platform names the tool or runtime that sent the request:
  • For MCP calls, it is the client’s tag as sent, for example claude-code, cursor, chatgpt, or codex. Clients choose their own tags.
  • For the CLI, it is the label in its user agent, for example codex from cd_cli ... (codex).
  • For everything else, it is a category based on your User-Agent header, such as python, node, curl, java, go_rust, browser, http_tool, or automation. It is none when you sent no user agent, and other when nothing matched.
New values can appear at any time, so do not hard-code the list. client_platform is empty for batch jobs, watch runs, and data exports, and usually for requests refused with a 429. Group by client_surface as well to tell those apart. You can group by client_platform, but you cannot filter on it.

Events

GET /account/usage/events returns your requests newest first, 100 per page by default and up to 500 with limit. It uses a cursor: while has_more is true, send next_cursor back as cursor with the same other parameters.
Python
client_surface says where a request came from: api, mcp, cli, dashboard, batch, watcher, export, or gateway for a request refused before it reached the API, such as a 429. Pass hide_free=true to hide successful calls that cost 0 credits on endpoints that never bill: /batch/... submits, /watcher/..., any endpoint ending in /autocomplete, /company/identify, and /screener/identify. It keeps three kinds of rows:
  • Errors on those endpoints. A 400 on /company/identify still shows.
  • Searches that matched nothing. A /person/search with 0 results costs 0 credits and still shows, since that is often the call you are debugging.
  • A batch job’s completion row, even when the job billed 0 credits. Only its submit row is hidden.
The flag applies even when you filter by endpoints. It defaults to false, and only /account/usage/events takes it: /summary and /errors ignore it. endpoint is the route template when the endpoint has path parameters, for example /watch/person/:watch_id/runs. The values are in request.path_params on the single-event endpoint. linked_ids names the job behind a request that did not come from a direct call, as batch_job_id, watch_id, export_id, or export_run_id. To see what you sent on one request, pass the X-Request-Id header from its response (the event’s event_id) to GET /account/usage/events/{request_id}. It adds request (body, query and path parameters), headers (with authorization and apikey shown as <redacted>), and response, the error body a failed request got back. response is null on a success and on a 429. A request id from another team returns 404, the same as one that never existed.

Errors by group

GET /account/usage/errors groups your failed requests by endpoint and error_key, the error message with your values masked as <v>, <n>, <values>, or <list>. Successes and 429 responses never appear. Each group’s kind tells you what to do: http_status and error_type are the ones the group’s requests got back most often. To list the requests in a group, pass its error_key to /account/usage/events. To open one, pass example_event_id to /account/usage/events/{request_id}. At most 1000 groups come back. truncated is true when the list was cut, and total_errors and by_kind count only the groups returned.

Examples

Group by component to split credits by what was charged. The response is trimmed to the first four rows.
bucket=1h returns timestamps in bucket_start. The response is trimmed to three rows.
The client_ip values are replaced with documentation addresses.
The client_ip value is replaced with a documentation address.
The response is trimmed to three groups.

Errors

Every error uses the same envelope, { "error": { "type", "message", "metadata" } }.

What to do next