Core concepts

Usage & audit log

Read what your integration called, what it cost, and what failed, on the Analytics tab.

Where to look

Every call your integration makes, REST and MCP alike, is recorded and shown on the Analytics tab of the developers hub. There are three views:

Overview: totals, credit burn per day, calls split by service, your top operations, spend per key, and every error code you hit.
MCP logs: one row per tool call your agents made.
API call logs: one row per /api/v1 request.

Click any row to see the full record: status, duration, credits, engines used, the error code, and the request id.

What counts as a call

Two surfaces are measured, and both are authenticated with an API key:

REST: any request to /api/v1.
MCP: tool calls your agent makes against the hosted MCP server at /api/mcp.

A local MCP server is not measured

If you run an MCP server on your own machine that your editor launches as a subprocess, it talks to your editor over stdin and stdout and never makes a request to OpenCharts. There is no key, no HTTP call, and nothing for us to record, so that usage will never appear here.

Only the hosted endpoint above produces MCP rows. If your MCP logs are empty while your agent is clearly working, check whether your client is pointed at a local command or at the hosted URL.

Both surfaces require the same plan as the rest of the API. On a plan without API access every request is refused before it runs, which is logged as denied rather than silently dropped.

Reporting windows

Pick a window in the top right of the tab. It applies to the charts and the logs together, and it lives in the URL, so you can bookmark or share "my MCP log for the last 30 days".

24h

window

Last 24 hours

7d

window

Last 7 days

30d

window

Last 30 days

90d

window

Last 90 days

What each row records

operation

string

The route template, for example GET /sheets/{id}/range, not the concrete path. That is what makes "how many calls to this endpoint" a countable number instead of one bucket per resource id.

service

string

The API service (REST) or tool group (MCP) the call belongs to. It comes from the same registry that generates the API reference, so a new endpoint is measured the day it ships.

outcome

ok | error | denied

denied is deliberately separate from error. A 401 or a rate-limited 429 never ran, so counting it as a failure would misreport both your success rate and your latency.

creditsCharged

integer

AI credits this specific call consumed, captured wherever the deduction happened, including deep inside an image render or a sheet edit. A call that failed after spending credits still reports them.

tokens

integer

Raw tokens behind the charge. Many endpoints bill a flat synthetic rate (an image is billed as a fixed token count), so this is one honest total rather than an invented input/output split.

latencyMs

integer

Server-side duration. Refused calls are excluded from the latency percentiles.

requestId

string

The same id returned on the response. Quote it when you contact support about one specific call.

keyId / keyPrefix

string

Which key made the call. The prefix is stored on the row, so a log entry stays readable even after you revoke and delete that key.

Arguments are never stored

For MCP calls the log records which argument keys a tool received, never the values. Your prompts, cell contents, and request bodies are your data and are not part of the audit record.

Why it's an audit log

The log is append-only, and not just by convention. The underlying collection grants no write permission to any user role, so rows can only ever be created by the server. There is no edit or delete action anywhere in the product, for you or for us.

The one way a row leaves is age. Entries are kept for 90 days and then pruned. If you need a longer history, export what you need before it ages out.

How fresh it is

Calls are buffered and written in batches, so a request you just made shows up within about a minute. The tab merges anything still in the buffer, which means a brand-new call usually appears immediately, marked writing… until its permanent record lands.

Very busy windows are annotated

A single report reads a bounded number of rows. If your window holds more than that, the Overview says so explicitly rather than quietly showing a partial total. Narrow the range for exact figures.

Reconciling credits

The Spend by keycard is the fastest way to answer "which integration is burning my credits". Credits are recorded against the call that caused them, so a batch job that quietly turned expensive shows up as a single operation rather than a mystery in your balance.

Refused calls cost nothing but are still logged. If your credits ran out mid-run you will see the exact call that hit the limit, with its error code, next to the ones that succeeded before it.