Purpose
Use SSE when your integration needs near real-time task state updates without repeated polling requests.Endpoint
SSE endpoints follow the same provider and model naming as standard generation endpoints, with an/sse/ segment in the path.
Request parameters
The SSE request body is the same as the matching non-SSE generation endpoint, so you can reuse the same model-specific payload.Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
provider | string | Yes | Model provider slug, for example google, openai, or kling-ai. |
model | string | Yes | Model slug under the provider, for example veo-3.1 or sora-2-pro. |
Headers
| Name | Required | Description |
|---|---|---|
Authorization: Bearer <YOUR_API_KEY> | Yes | API authentication header. |
Content-Type: application/json | Yes | Indicates JSON request body format. |
Accept: text/event-stream | Recommended | Explicitly requests SSE stream responses. |
Request body example
Response example
A successful SSE request returns200 OK with Content-Type: text/event-stream. The stream sends incremental status updates and ends when the task reaches a terminal state.
Error handling notes
When the request fails before the stream is established, the API returns standard JSON error responses.| Status | Meaning |
|---|---|
400 | Invalid request body or missing required fields |
401 | Missing or invalid API key |
404 | Provider or model route not found |
422 | Validation error |
429 | Rate limited |
500 / 503 | Transient server-side error |
Operational behavior
Design client logic for streaming workloads and transient network failure.- Rate limits:
PLACEHOLDER_RATE_LIMITS - Timeouts:
PLACEHOLDER_TIMEOUTS - Retry behavior:
PLACEHOLDER_RETRY_POLICY
Retry guidance
Retrying aPOST can create duplicate generation jobs if the first request was accepted but the client disconnected. Use idempotency controls if your backend provides them, or reconcile task IDs before retrying create calls.