Skip to main content

Overview

The API uses standard HTTP status codes and returns error details in a consistent format. All errors include a detail field with a human-readable message.

Error Response Format

All error responses follow this structure:

HTTP Status Codes

400 Bad Request

Returned when the request is malformed or missing required parameters. Common scenarios:
  • No utterances detected in media (NO_UTTERANCES)
  • File too large (FILE_TOO_LARGE)
  • Missing timeline for segmentation endpoint
  • Invalid file format
  • Empty chunk data uploaded
Example:

401 Unauthorized

Returned when authentication fails. Scenarios:
  • Missing X-API-Key header (INVALID_KEY)
  • Invalid API key provided (INVALID_KEY)
  • API key not in allowlist (INVALID_KEY)
Example:
You can also pass the API key as a query parameter: api_key=<client key> when custom headers are not available.

404 Not Found

Returned when a requested resource doesn’t exist. Scenarios:
  • Unknown live session ID
  • Invalid endpoint path
Example:

409 Conflict

Returned when there’s a conflict with the current state. Scenarios:
  • Concurrent SSE attach (only one SSE consumer per live session)
  • Wrong chunk sequence number (chunks must be uploaded sequentially)
  • Session already finalized
  • Attempting to upload to a finalized session
Example:

500 Internal Server Error

Returned when server-side processing fails. Common causes:
  • Downstream agent or ASR failure (ANALYSIS_FAILURE)
  • External service failures
  • Media processing errors
  • General pipeline failures
Example:

SSE Error Events

SSE streams may emit error events with specific error codes:

Error Event Format

Error Codes

string
Media contained no speech above the threshold. Analysis cannot proceed.
string
Exceeded MAX_FILE_SIZE_MB (default 500 MB). Upload fails before processing.
string
Missing or incorrect API key. Verify header or query parameter.
string
Downstream agent or ASR failure. Details provided in detail field.
string
Live ASR connection failed. The live streaming session cannot continue.
string
General streaming failure. The SSE connection may close after this event.
Example SSE error:

Best Practices

Retry Logic

  • 401 errors: Check API key configuration. Do not retry with the same key.
  • 400 errors: Fix the request payload. Do not retry without changes.
  • 404 errors: Verify resource IDs. Do not retry.
  • 409 errors: Resolve the conflict (e.g., wait for current SSE consumer to disconnect). Retry after resolution.
  • 500 errors: Implement exponential backoff. These may be transient.

Error Handling in SSE Streams

When consuming SSE streams:
  1. Listen for error events: Always handle error events in your SSE client
  2. Handle connection drops: Implement reconnection logic for network failures
  3. Validate event data: Parse JSON carefully and handle malformed events gracefully
  4. Log errors: Record error codes and messages for debugging
Example JavaScript SSE error handling:

Chunk Upload Error Handling

When uploading chunks to live sessions:
  • 409 on wrong sequence: Use the next_chunk_seq from the previous response
  • 404 on unknown session: Verify session ID and check if session expired
  • 409 on finalized session: Session is complete; do not upload more chunks
Example retry logic:

Operational Notes

Session TTL Management

Live sessions expire after a default TTL (900 seconds). To prevent expiration:
  • Call POST /analyze/live/{session_id}/control with {"action": "keepalive"} during long pauses
  • Monitor expires_at timestamp from session start response
  • Upload chunks regularly to keep session active

File Size Limits

Files exceeding MAX_FILE_SIZE_MB (default 500 MB) will be rejected with a 400 error before processing begins. Check file size client-side before upload.

Prosody Fallbacks

If audio processing fails post-stream, the service still returns textual insights. Prosody fields may be empty in the response. This is not an error condition.

Error Handling & Troubleshooting

Logs are available server-side. Look for [conversation_id] prefixes for correlated traces.

Debugging Tips

  1. Check logs: Server-side logs are available for debugging
  2. Verify artifacts: Check artifact_dir paths in responses for debugging
  3. Monitor metrics: Use /metrics endpoint to watch SSE throughput and latency
  4. Validate OpenAPI: Ensure your requests match the OpenAPI specification
  5. Correlate traces: Look for [conversation_id] prefixes in logs for debugging specific conversations