Skip to main content
Good AI Sonar observability starts with public identifiers. Your logs should help you answer “what did the user request, what public task did AI Sonar create, and how was it billed?” without exposing sensitive provider details or sensitive user data.

​
Public Identifiers To Capture

Do not store provider task IDs, provider URLs, provider identifiers, Redis keys, or sensitive execution metadata as customer-facing records.

​
What To Log

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.
  • Sanitized request shape: which fields were present, not the full prompt or private media content.
  • Terminal async status responses, including public error fields.
  • Client retry count and whether the retry created a new task or resumed an existing one.
Always redact Authorization, API keys, signed URLs, private media URLs, full prompts, and user personal data unless you have explicit permission to retain them.

​
Troubleshooting Matrix

​
Support Packet Template

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.
  • Sanitized request shape and public error body.
  • Your expected result and what the user actually saw.
Do not include API keys, private media, full prompts, private URLs, or diagnostic identifiers unless AI Sonar support explicitly asks for a redacted sample.

​
Operational Checks

  • Alert on repeated 401, 402, 429, and 5xx responses separately; they usually have different owners.
  • 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 Reference