Analytics answers three questions: how many credits you are spending, what you are spending them on, and what happened to your account. The first two are on the Usage tab, the third on Audit history.
Credit usage
The chart shows credits consumed per day over the last 7, 14 or 30 days. The stat row above it carries the totals — this cycle's consumption, the lifetime figure, and your error rate as a percentage of all requests.
Read the shape rather than the number. Three patterns are worth recognising:
- A step change that starts on one day and holds means a deployment. Correlate it with a release and you have your answer in one look.
- A spike that decays is usually a backfill, a migration, or a retry loop that eventually gave up. A retry loop is worth finding, because it spends credits on calls that were never going to succeed.
- A slow climb is growth, and the useful thing to do with it is arithmetic: project the line to the end of the cycle and you know whether to change plan before you run out rather than after.
Export CSV downloads the windowed data — date and credits, one row per day — which is the short path to a spreadsheet or a chart of your own.
Where the credits go
The per-API breakdown ranks endpoints by calls, with each one's share of the total. This is the panel that turns "usage went up" into something actionable.
Two things it commonly reveals:
One endpoint dominating. That is normal and not a problem in itself — but if it is a cacheable lookup (a country record, a currency symbol, an ISO code), it is also the cheapest optimisation available, because a cached response costs nothing. The cache-window guidance in making requests is a reasonable starting point.
An endpoint you did not expect. Usually a debug loop, a health check calling a real endpoint instead of a cheap one, or a test suite pointed at production credentials. All three are fixed by knowing about them.
Multi-credit endpoints skew the ranking: an endpoint called half as often as another can cost more than it. Compare credits, not just calls.
Recent API calls
The call log lists individual calls with the source, the outcome, the latency and the credit cost. It is available on paid plans.
This is the diagnostic view. When an integration misbehaves, it separates the three cases that look identical from the client side:
| What you see | What it means |
|---|---|
| The call is not listed | It never reached the API — check the key format and your network, not the endpoint |
Listed with a 4xx | It arrived and was rejected. The status says why; see errors |
Listed with a 200 but slow | It worked. The latency column tells you where the time went |
Latency here is measured at the API, so it excludes your network and your own processing. A call that reads as 90 ms in this log and 900 ms in your application is telling you the other 810 ms is yours.
Audit history
The audit trail records security-relevant account events rather than API traffic: key rotations, sub-key creation and deletion, team membership changes, sign-in method changes. Each entry has the action, a description, who did it and when.
It is a Mega-plan feature, with 90-day retention and a full CSV export.
Where the call log answers "what did my code do", this answers "what did a person do" — which is the question that matters when a key stops working and nobody remembers rotating it, or when someone needs a record for a compliance review.
Reading usage from code
You do not have to open the dashboard to know where you stand. Every response carries your remaining balance:
x-api-remaining-credits: 4821
That is exact and current, where the dashboard's figures are aggregated and lag slightly. Logging it, or alerting when it drops below a threshold, costs nothing extra — it comes back on calls you were making anyway.
For a programmatic summary rather than a per-response number, the analytics API returns your usage, plan and balance as a normal endpoint.
Next
Rate limits explains the ceilings behind the numbers here. Billing is where a plan change happens once analytics tells you one is due.