Skip to main content
Use this checklist before sending live financial events.

​
Credentials and environments

  • Create separate keys for development, staging, and production.
  • Use write keys for senders and read keys for readers.
  • Use admin only when one service must read and write.
  • Store secrets in a secret manager.
  • Rotate a key after exposure.

​
Event identity

  • Set a stable event.id in the source system.
  • Keep the same ID and payload when retrying.
  • Treat events without IDs as unsafe to retry.
  • Do not reuse an ID for different event content.

​
Batches and concurrency

  • Keep each batch between 1 and 500 events.
  • Keep the request body below 5 MiB.
  • Keep each event below 256 KiB.
  • Bound concurrent requests in your sender.
  • Preserve the index of every batch result.

​
Retry behavior

  • Retry 503 with exponential backoff and jitter.
  • Retry rejected event items only after fixing the input.
  • Do not retry unchanged 400, 401, 403, or 404 responses.
  • Treat an event duplicate result as success for delivery purposes.
  • Treat idempotency_conflict as a data-integrity error that needs review.

​
Observability

  • Record X-Request-ID for every response.
  • Count accepted, duplicate, and rejected results.
  • Alert on rising rejection or conflict rates.
  • Do not log bearer tokens or raw financial payloads.

​
Issue workflows

  • Use a read key to list and inspect issues.
  • Use a write key to assign issues and add notes.
  • Use Idempotency-Key when a note request can be retried.
  • Do not send an idempotency header for assignment updates. Assignment is repeatable.

​
Data handling

  • Redact financial data from logs and tickets.
  • Treat issue messages and notes as customer data.
  • Do not send raw API responses to external AI systems.
  • Review access to member IDs and organization data.