Data handling & retention

Each API call leaves two kinds of data behind: a record of the call (who called, which model, how many tokens, what it cost) and, depending on the key’s data mode, the content of the call. They are handled differently: the record is your usage and billing history; the content can be erased on a schedule your organization chooses.

What is recorded for each call

Every call that is admitted and sent to a model is journaled. (A call refused at admission — an invalid key, a missing scope, a rate limit — is answered immediately and leaves no such record.) GET /v1/requests/{id} returns these fields of the record:

Field	Content
`request_id`, `api_key_id`, `created_at`	Which key made the call, and when.
`status`, `http_status`, `duration_ms`	`succeeded`, `failed` or `blocked`, the HTTP status, the duration.
`model_served`	The model that served the call.
`usage`	Input, output, cached, cache-write and reasoning tokens.
`cost`	Cost in USD and credits, its source (`pending`, `estimated`, `reconciled`), and the amount reserved and settled against your key.
`tags`	The attribution tags of the call.

GET /v1/requests/{id} never returns content. Alongside this record, the call also produces a billing ledger entry (except on sandbox keys, which are never billed) and a reservation against your key, settled when the call ends.

Content: what may be stored

standard keys. The journal entry may also contain the content of the call — the prompt and the model’s output — for support and debugging. It stays until your organization’s retention period erases it (below).
zero_retention keys. No content is stored: no prompt, no output, no hash of either, no image URL. See Zero data retention.
Tags are not content. Tags, including the OpenAI metadata field, are part of the record in every mode and are not erased by the retention period. Keep personal data out of them.

Answers kept for idempotent retries

When you send an Idempotency-Key with a standard key, the JSON answer is kept so that a retry within 24 hours gets the same result. Once that window has passed, a daily cleanup removes it. Streamed answers and answers to zero_retention keys are never kept for replay.

In every mode, an Idempotency-Key also keeps a fingerprint of the request body, to detect the same key sent with a different body. It is a keyed hash (HMAC-SHA256) computed with a secret held only by Belarel’s servers, never the body itself, and it is removed on the same schedule.

Retention of content

Your organization decides how long call content is kept. An owner or admin sets it in the organization dashboard, under Data & Compliance → Retention Policies → AI log content:

Choose 30, 90, 180 or 365 days, or No automatic erasure.
A daily job erases the content of journal entries older than the period you chose, normally within a day of the period passing (it works in batches). It erases the system and user prompts, the model’s outputs, the hashes of prompts and outputs, image URLs and content-derived cache keys. Other parts of the record, such as error messages and any output schema recorded with the call, are not erased.
The setting covers the AI content of your whole organization, including API calls.

Erasure applies to content only. The record of the call — its tokens, cost, model, status and tags — stays, because it is your usage and billing history.

What retention never deletes

The journal record of each call, and its token counts and cost.
The billing ledger entries.
Settled reservations, which trace the money counted against your keys’ caps.

Reservations that were released (a call refused after its reservation, for example) carry no spend; they are deleted after 7 days.

Deletion requests

There is no API endpoint to delete an individual call or its record. The retention period is the control for content. If you need content erased before your retention period would erase it, contact Belarel support and quote the request ids concerned.

Practical guidance

Decide your retention period before going to production, and document it in your own records of processing.
Route sensitive workloads through a zero_retention key rather than relying on erasure after the fact.
Keep the X-Request-Id of the calls you may need to discuss with support: it is the key to every record listed on this page.