Logs and troubleshooting

Keep TokenLab request, task, and billing IDs in your logs. They connect a user action to its result and charge without storing the prompt or private media.

In the Console, captured request and response details are available for 30 days from capture, with access ending at the exact expiry even if physical cleanup is still queued. Request identity and billing/usage history have independent lifetimes. See Data retention.

From a request to an investigation and supportCopy Anchor Link

1. Open Requests in the workspace that owns the request. Find its Request ID and select the row.

2. Choose Open full details for a dedicated page. Back to requests restores the list filters. A link never grants access to another workspace; use an account authorized for that workspace.

3. For pending or unknown status, refresh progress first. For a failure or interrupted response, choose Investigate the issue when available. This starts an investigation for that request in the in-app Agent; it does not replay the original model request. Successful requests do not need an investigation by default.

4. If you still need help, choose the human-support action from the request or investigation. It opens a preview with the linked request and conversation when available. Review the summary and remove private content, then explicitly select Submit. An investigation or a preview alone does not send a support request.

5. After submission, keep the confirmation and continue the same conversation in Support. Reuse it for replies and extra information instead of submitting duplicates.

IDs to keepCopy Anchor Link

Customer-facing records should use TokenLab IDs. Never expose private service URLs, cache keys, or diagnostic metadata.

What To LogCopy Anchor Link

Log enough to diagnose the request without leaking secrets:

• Endpoint, HTTP method, model, status code, timestamp, and latency.
• Public identifiers: request_id, task_id, poll_url, and billing_transaction_id when present.
• Field names sent in the request, not the full prompt or private media content.
• Final async status responses and safe error fields.
• Client retry count and whether the retry created a new task or resumed an existing one.

Always redact Authorization, API keys, management tokens, signed URLs, private media URLs, full prompts, and user personal data unless you have explicit permission to retain them.

Troubleshooting MatrixCopy Anchor Link

Usage ReconciliationCopy Anchor Link

Use the Management API for server-side reconciliation:

curl "https://api.tokenlab.sh/v1/management/api-keys/key_abc123def456/usage?page=1&limit=20&scene=video" \
  -H "Authorization: Bearer mt-your-management-token"

GET /v1/management/api-keys/{keyId}/usage can filter by scene, model, modelVendor, startDate, and endDate. Use these records instead of scraping Console pages or calculating charges from response token counts alone.

Streaming responses may settle after the stream is sent, so a billing header can be absent even when usage is later recorded. Async media tasks may settle after terminal polling.

What to send supportCopy Anchor Link

When contacting support, include:

• request_id.
• task_id and poll_url for async work.
• billing_transaction_id when present.
• Endpoint, method, model, timestamp, and status code.
• Request field names and the safe error body.
• Your expected result and what the user actually saw.

Do not include API keys, management tokens, private media, full prompts, private service URLs, or diagnostic identifiers. If support needs a request example, send a redacted copy.

Checks worth automatingCopy Anchor Link

• Alert on repeated 401, 402, 429, and 5xx responses separately; each needs a different response.
• Track async jobs that remain non-terminal longer than your product SLA.
• Track duplicate create attempts for the same user job ID.
• Sample completed jobs and verify the user-visible asset, usage record, and stored task record agree.

API ReferenceCopy Anchor Link