Tracking cloud spend from autonomous agents and serverless infrastructure is a major bottleneck when relying on manual dashboard exports. Engineering teams need a programmatic way to monitor costs across usage-based ecosystems.
- REST API Integration: Query the new Cloudflare `/billable-usage` endpoint via GET request using a token with Billing Read permissions.
- FinOps Alignment: Process the JSON payload, which borrows naming conventions from the FOCUS standard, to map costs to internal schemas.
- Cost Attribution: Automate financial reporting and attribute shared expenses for services like Workers, R2, and D1 to specific internal teams.
Data is only updated once daily (preventing real-time automated kill switches for rogue scripts), excludes Enterprise accounts for now, and requires custom data adapters due to incomplete specification compliance.
Script
The Catch: A Daily Summary for an Autonomous World
Cloudflare just wrapped up something they called "Agents Week." The premise of their marketing blitz was that AI agents are now writing code, deploying Workers, and provisioning infrastructure on your behalf. Because software is spending your money autonomously, Cloudflare argues you need to track that spend—and they explicitly said you need to track it "throughout the day."
To solve this, they just released a new Billable Usage REST API. It sounds like exactly what you want: a programmatic way to monitor what your infrastructure is costing you. Except, if you read two paragraphs past the headline, there is a massive catch. The usage and cost data in this new API is only updated once a day. You are handing over the company credit card to an autonomous agent, and your primary method for monitoring its spending habits is a daily summary. The irony is heavy.
Does this let you build a real-time kill switch for runaway cloud spend? No.
Picture this. It's Friday evening. You deploy an autonomous agent to handle some database maintenance. The agent hits an edge case, encounters an infinite loop, and starts spinning up millions of D1 queries. You're a responsible engineer, so you wrote a cron job that pings Cloudflare's new billing API to monitor for exactly this kind of anomalous spike. Your script is running, checking the usage every ten minutes. But because Cloudflare's backend only aggregates this data daily, your automated circuit breaker sees nothing. It thinks everything is fine. Your script doesn't trigger the kill-switch until the API data finally updates on Saturday morning. By then, the damage is done. The billing delay guarantees your script is blind while the meter is running.
How The API Actually Works
So what is this API actually doing? It's a single endpoint: /client/v4/accounts/$ACCOUNT_ID/billable-usage. You hit it with a GET request. You pass a standard API token with Billing Read permissions. It hands back an HTTP 200 OK with a JSON payload.
Each row in that array represents one charge period for one product on your account. You get the service name, like "Workers Standard". You get the charge period start and end. You get the consumed quantity, measured in whatever unit that specific service bills by—GB-months, or requests. And you get the contracted cost in your billing currency.
Setting the request up is trivial. The friction comes entirely from the downstream data engineering. You still have to handle pagination. You still have to map Cloudflare's specific service categories to your internal accounting schema. And you have to build logic to handle that massive daily ingestion lag.
Compliance with the FOCUS Standard
Does the API output proprietary formats or something standard? Cloudflare says they made a deliberate choice to match the FOCUS standard—the FinOps Open Cost and Usage Specification. If you're already pulling FOCUS data from AWS or Google Cloud, the column names here will look familiar. They use exactly the same casing for fields like BillingCurrency and ChargePeriodStart.
But they immediately concede they aren't fully compliant with the specification yet. A handful of columns required by the FOCUS standard are completely missing from the payload. That means you aren't actually getting a standardized output. You're getting a proprietary Cloudflare schema that happens to borrow familiar column names. You can't just drop this into an existing FinOps pipeline without writing a custom adapter. It's close to the spec, but close means your data pipeline will still throw a validation error.
Who Is This For (And Who Should Wait)?
Can you use this on your Enterprise account right now? No. If you operate on an Enterprise contract, skip this release entirely. The endpoint currently only works for self-serve accounts. Enterprise users are explicitly excluded for now, though Cloudflare says coverage is in the works.
You should also skip this if your Cloudflare bill is highly predictable and driven entirely by flat-rate plans rather than usage-based serverless products. There's no value in polling an API for a number that never changes.
The Verdict: An Accounting Tool, Not an Operational One
When you strip away the Agents Week framing, this isn't a tool for monitoring AI. It's a standard programmatic billing API. Cloud providers have offered these for standard engineering teams for over a decade. Relying on manual dashboard CSV exports has always been a bottleneck for FinOps workflows.
If your team is heavily invested in Cloudflare's usage-based ecosystem—Workers, R2, D1, Vectorize—and you need to programmatically attribute shared costs to specific internal engineering teams, this endpoint is a massive upgrade. It beats clicking download on a visual dashboard. It's exactly what you need for end-of-month financial reporting.
Just be precise about its actual utility. It fails the core developer use case. Until Cloudflare reduces that ingestion delay from a daily batch to a real-time stream, you can't use this API to defend your infrastructure bill against rogue scripts. It's an accounting tool, not an operational one.
TAKEYOURPILLS.TECH. Go ship something.