Do I need an account with Anthropic?

Yes. You connect your own Anthropic account once, from Ingest, and the data comes from what that account can see.

How fresh is the data?

As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan.

Will running it again create duplicate rows?

No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.

Do I need to write code?

No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

Anthropic

Analytics

Ready to use

Anthropic data, published as Anthropic publishes it. Ingest delivers this data to a data warehouse you own as 8 tables, and updates it on the schedule you choose. There is no code to write and nothing to install.

What you get

Table	Each row is
api_keys `api_keys`	Every API key in the organization: name, status, scope, expiry and who created it, one row per key merged on `id` and re-read about once a day, so new keys and status changes appear. Only a partial hint of each key is returned, never the key itself. Anthropic has deprecated the top-level `workspace_id`, which is null both for keys in the Default workspace and for keys with no workspace scope; `scope` says which. `created_by`, `principal` (the user or service account a key acts as) and `scope` are kept as JSON.
compliance_settings `compliance_settings`	Whether the organization's Compliance API is turned on: one row, `state__type` enabled or disabled, re-read about once a day.
cost_report `cost_report`	Daily Claude API cost in USD. Each `cost_report` row is one UTC day, and its cost lines are in the `cost_report__results` child table: one line per workspace and description (such as "Claude Sonnet 5 - Input Tokens"), with the model, cost type, token type, service tier, context window and inference geography Anthropic parses from it. `amount` is a decimal string in cents of USD (598.0346 is $5.98). Priority Tier costs are not in this report; Anthropic reports Priority Tier only as usage. `workspace_id` is null for the Default workspace. Days load the same way as usage_report: once the day has ended, each day once, and the first sync loads all history, from 2023-01-01, unless you choose how far back it reaches.
organization `organization`	The Claude Console organization the admin key belongs to: its `id` and `name`, one row, re-read about once a day.
rate_limits `rate_limits`	The organization's Messages API rate limits, as the Console's Rate limits page shows them. One row per rate limit group: a model family (`group__display_name`, such as Claude Sonnet 5) or an API such as Message Batches, Files, Token Counting, Skills or web search (`group__type`). Each group's limits are in the `rate_limits__limits` child table, one line per limiter (`type`, such as requests_per_minute, and `value`); `models` lists the model IDs and aliases a model group covers, as JSON. `group__id` is the same in every organization. The table is replaced about once a day, so a limit Anthropic changes appears. Workspace overrides are not included.
usage_report `usage_report`	Daily Claude API token usage. Each `usage_report` row is one UTC day (`starting_at` to `ending_at`), and its usage lines are in the `usage_report__results` child table: one line per model, workspace, API key, service tier and context window used that day, with uncached input, cache read, cache creation and output tokens and web search requests. Anthropic allows five group-by dimensions, so inference geography and speed are not split out and come back null. `workspace_id` is null for the Default workspace and `api_key_id` is null for Console playground usage. A day is loaded once it has ended, so the newest day is yesterday (UTC). Each run asks from the last day it loaded, which comes back again and is skipped, so a day is loaded once and not refreshed. A day with no usage still has a row, with no lines. The first sync loads all history, from 2023-01-01, unless you choose how far back it reaches.
users `users`	Every member of the organization: name, email, organization role and when they joined (`added_at`), one row per member. The table is replaced with the current list about once a day, so a member who is removed leaves it and a role change appears. Pending invitations are not members and are not loaded.
workspaces `workspaces`	Every workspace in the organization, including the Default workspace and archived workspaces (the request asks for both: without include_default an organization with only the Default workspace returns nothing, and without include_archived an archived workspace would drop out of the list and keep a null `archived_at`). One row per workspace, merged on `id` and re-read about once a day, so a new workspace appears and an archived one gets its `archived_at`. In usage_report and cost_report the Default workspace appears as a null `workspace_id`, not as its `id` here.

How it works

Choose Anthropic. Connect your Anthropic account once, from Ingest.
Pick where it goes. BigQuery, Snowflake, Databricks, Redshift and 10 more, in an account you own.
Pick a schedule. Daily is the default, and weekly and monthly are there too.
Ingest runs it from then on. If a run fails, your dashboard shows which table and why.

Questions

Do I need an account with Anthropic?: Yes. You connect your own Anthropic account once, from Ingest, and the data comes from what that account can see.
Which warehouses can Anthropic data go to?: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL and Snowflake, in an account you own.
How fresh is the data?: As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan.
Will running it again create duplicate rows?: No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.
Do I need to write code?: No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

For your data team: technical reference

Connector anthropic, version 0.1.0, a REST source, status beta, authentication api_key.

Vendor documentation: https://platform.claude.com/docs/en/manage-claude/usage-cost-api

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`api_keys` Every API key in the organization: name, status, scope, expiry and who created it, one row per key merged on `id` and re-read about once a day, so new keys and status changes appear. Only a partial hint of each key is returned, never the key itself. Anthropic has deprecated the top-level `workspace_id`, which is null both for keys in the Default workspace and for keys with no workspace scope; `scope` says which. `created_by`, `principal` (the user or service account a key acts as) and `scope` are kept as JSON.	beta	staleness	merge	`id`	-
`compliance_settings` Whether the organization's Compliance API is turned on: one row, `state__type` enabled or disabled, re-read about once a day.	beta	staleness	replace	-	-
`cost_report` Daily Claude API cost in USD. Each `cost_report` row is one UTC day, and its cost lines are in the `cost_report__results` child table: one line per workspace and description (such as "Claude Sonnet 5 - Input Tokens"), with the model, cost type, token type, service tier, context window and inference geography Anthropic parses from it. `amount` is a decimal string in cents of USD (598.0346 is $5.98). Priority Tier costs are not in this report; Anthropic reports Priority Tier only as usage. `workspace_id` is null for the Default workspace. Days load the same way as usage_report: once the day has ended, each day once, and the first sync loads all history, from 2023-01-01, unless you choose how far back it reaches.	beta	watermark	merge	`starting_at`	backfill_days
`organization` The Claude Console organization the admin key belongs to: its `id` and `name`, one row, re-read about once a day.	beta	staleness	replace	`id`	-
`rate_limits` The organization's Messages API rate limits, as the Console's Rate limits page shows them. One row per rate limit group: a model family (`group__display_name`, such as Claude Sonnet 5) or an API such as Message Batches, Files, Token Counting, Skills or web search (`group__type`). Each group's limits are in the `rate_limits__limits` child table, one line per limiter (`type`, such as requests_per_minute, and `value`); `models` lists the model IDs and aliases a model group covers, as JSON. `group__id` is the same in every organization. The table is replaced about once a day, so a limit Anthropic changes appears. Workspace overrides are not included.	beta	staleness	replace	`id`	-
`usage_report` Daily Claude API token usage. Each `usage_report` row is one UTC day (`starting_at` to `ending_at`), and its usage lines are in the `usage_report__results` child table: one line per model, workspace, API key, service tier and context window used that day, with uncached input, cache read, cache creation and output tokens and web search requests. Anthropic allows five group-by dimensions, so inference geography and speed are not split out and come back null. `workspace_id` is null for the Default workspace and `api_key_id` is null for Console playground usage. A day is loaded once it has ended, so the newest day is yesterday (UTC). Each run asks from the last day it loaded, which comes back again and is skipped, so a day is loaded once and not refreshed. A day with no usage still has a row, with no lines. The first sync loads all history, from 2023-01-01, unless you choose how far back it reaches.	beta	watermark	merge	`starting_at`	backfill_days
`users` Every member of the organization: name, email, organization role and when they joined (`added_at`), one row per member. The table is replaced with the current list about once a day, so a member who is removed leaves it and a role change appears. Pending invitations are not members and are not loaded.	beta	staleness	replace	`id`	-
`workspaces` Every workspace in the organization, including the Default workspace and archived workspaces (the request asks for both: without include_default an organization with only the Default workspace returns nothing, and without include_archived an archived workspace would drop out of the list and keep a null `archived_at`). One row per workspace, merged on `id` and re-read about once a day, so a new workspace appears and an archived one gets its `archived_at`. In usage_report and cost_report the Default workspace appears as a null `workspace_id`, not as its `id` here.	beta	staleness	merge	`id`	-

Setting up the destination is its own short guide, one per warehouse or lake: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL, Snowflake.

Get Anthropic data into your warehouse

Last updated 2026-10-14.