Skip to main content
Understanding API error responses and implementing proper error handling is crucial for building reliable integrations with the Streamforge External API.

HTTP Status Codes

The API uses standard HTTP status codes to indicate request outcomes:

Error Response Format

All error responses follow a consistent structure:
The request_id can be used when contacting support about specific errors.

Handling Specific Errors

400 Bad Request

Invalid parameters or malformed requests:
Common causes:
  • Invalid platform value (must be twitch, youtube, or tiktok)
  • limit out of range (must be 1-50)
  • Missing required fields in bulk requests
  • Invalid date format in query parameters

401 Unauthorized

Missing API key:
Solution: Ensure all requests include the x-api-key header.

403 Forbidden

Invalid or revoked API key:
Common causes:
  • Typo in API key
  • Key was rotated or revoked
  • Key is inactive

404 Not Found

Resource doesn’t exist:
Note: 404s are normal in some scenarios:
  • Profile IDs that don’t exist
  • Content that was deleted
  • Games not in the database
Handle 404s gracefully rather than treating them as errors.

429 Too Many Requests

Rate limit exceeded:
Response headers:
  • Retry-After: Seconds to wait before retrying
  • X-RateLimit-*-remaining: Remaining quota (often 0)

Retry Strategies

Exponential Backoff

Implement exponential backoff for retryable errors (429, 5xx):

Handling Bulk Operation Errors

Bulk operations use partial success - some items may be missing:

Best Practices

Always check response status before parsing JSON. Some errors may not return JSON bodies.
  • Check status first: Verify response.ok or response.status before parsing JSON
  • Handle 404s gracefully: Missing resources are normal; don’t treat as errors
  • Respect Retry-After: For 429 errors, wait the specified time before retrying
  • Log request IDs: Include request_id from error responses in your logs
  • Monitor error rates: Track error rates to detect issues early
  • Implement circuit breakers: Stop retrying if error rate is too high

Example: Complete Error Handler

Don’t retry 4xx errors (except 429) - they indicate client errors that won’t be fixed by retrying.