What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To show AI video generation progress in real time, treat each render as a durable server-side job: submit it through a normal HTTP request, receive completion or failure from a provider webhook when available (or poll with a deadline), then send normalized job updates to the browser over Server-Sent Events (SSE). SSE carries status notifications—not the generated video or a stream of its frames.
How the workflow fits together
There are three separate connections in this design. Keeping them separate makes long-running renders easier to recover and lets you change providers without changing the browser interface.
- Browser to application: The browser submits the prompt and options with a normal POST request. The application validates the request, creates a durable job record, submits the generation request to the provider, stores the provider’s job ID, and returns the application’s job ID. The initiating request should not stay open for the duration of a render.
- Provider to application: A webhook can notify the application when a provider-side job changes state. If the provider does not offer a webhook, a background worker can check its status endpoint.
- Application to browser: The browser opens an SSE connection to receive lifecycle updates. The application—not the provider—translates provider-specific statuses into the events your UI understands.
This pattern is appropriate because video generation can be asynchronous. OpenRouter’s video API guidance documents job-status polling and webhook callbacks; Gemini’s webhook documentation includes a video.generated event for completed video operations. Those are provider-specific capabilities, not a universal webhook contract.
Free tools Windows power users keep installed
One-click scans. No signup required.
Should you use SSE or webhooks for an AI video generation API?
They solve different problems and are often used together. A webhook is a provider-to-server notification; SSE is a server-to-browser notification. A webhook does not replace the browser event stream, and SSE does not notify your server when a provider-side job finishes.
#1 Best Overall
| Mechanism | Connection | Best use | What it does not establish |
|---|---|---|---|
| Webhook | Provider to your server | Notify your backend of a provider-side event, such as a completed or failed job. | It does not guarantee every provider offers intermediate progress or identical delivery semantics. |
| Polling | Your background worker to provider status endpoint | Check unresolved jobs when webhooks are unavailable, or reconcile a job whose callback may have been missed. | It does not provide instant updates; the observed timing depends on your polling schedule and provider status behavior. |
| SSE | Your server to the browser | Push application job-state updates to a page over a one-way HTTP event stream. | It does not carry client commands upstream or inherently deliver video frames. |
MDN describes EventSource as one-way: the browser can receive events but cannot send data on that same connection. Send prompts, cancellation requests, and edits through ordinary HTTP endpoints, or choose a separate bidirectional transport if the application needs one.
How to model jobs and lifecycle events
Persist the application’s view of each job, including its own stable ID and the provider’s job ID. Keep provider-specific payloads at the integration boundary; the browser should receive a small, consistent event shape regardless of which provider ran the job.
{
"jobId": "app-job-123",
"status": "running",
"updatedAt": "2026-10-11T12:00:00Z",
"result": null,
"error": null
}The values above illustrate a schema, not a provider response or a required timestamp format. A practical lifecycle can use named events such as job.queued, job.running, job.completed, and job.failed. Include a result pointer only when one is available, and include an error safe for the client to display when a job fails.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Do not display a percentage unless the provider supplies a meaningful progress value. A status such as “rendering” is more accurate than a made-up progress bar when the API reports only that the job is still running.
Rank #2
How to receive provider webhooks safely
Webhook event names, payload fields, signatures, replay protections, and delivery guarantees depend on the provider. Implement against that provider’s current documentation rather than treating one integration’s behavior as standard.
- Verify the request. Apply the provider’s exact signature-verification procedure and validate any documented timestamp or replay constraints. Do not trust an HTTP POST merely because it reached your callback endpoint.
- Identify the delivery. Record a stable provider event or delivery ID where available. Gemini’s webhook guidance uses
webhook-idfor deduplication and describes at-least-once delivery; the same event may therefore arrive more than once. - Validate the transition. Check that the event belongs to a known provider job and that its status transition is valid for the application’s current record. Make handling idempotent so replaying a delivery cannot create a second result or roll a completed job back to running.
- Persist before notifying. Update job state and record the processed event transactionally. Only after the durable state is saved should the application publish an SSE notification.
- Acknowledge promptly. Once the callback is authenticated and accepted for processing, return the appropriate success response quickly. Put slow file retrieval, media processing, and other expensive work in a queue rather than holding the webhook request open. Gemini recommends prompt 2xx acknowledgement and asynchronous processing.
OpenRouter documents an idempotency header and optional webhook signature verification. The exact header and verification steps must be taken from its current documentation; do not assume these match another provider’s contract.
How to keep SSE updates reliable across reconnects
An SSE stream is an HTTP response with a text/event-stream content type. Its event format supports event, data, id, and retry fields. The event name distinguishes lifecycle changes, the data carries the payload, the ID can identify a replayable event, and retry specifies a reconnection delay in milliseconds.
event: job.running
id: 42
data: {"jobId":"app-job-123","status":"running"}
In the browser, an EventSource connection reconnects automatically after a disconnection. If the server provides event IDs and retains a replay log, it can use the client’s last-event ID to resume delivery. If no replay log exists, the client should fetch the current durable job state after reconnecting; otherwise a transition sent while it was offline may be missed.
Support both a current-state read and live updates. A robust page can load the job record first, open the stream, and reconcile any events that arrive during the handoff using event IDs or state versions. If a stream reconnects and the server cannot replay history, send the current snapshot rather than pretending that all intermediate transitions were preserved.
Idle connections may be closed by proxies or other intermediaries. SSE comment lines can serve as heartbeats to help keep a stream alive. Close streams when the client no longer needs updates. If a page tracks many jobs, consider one multiplexed user stream instead of one connection per job; MDN notes that browsers impose a low per-browser/per-domain SSE connection limit without HTTP/2.
What to do when the provider has no webhook
Use a background worker to check the provider’s job-status endpoint with bounded backoff and a deadline. Persist each observed transition and publish it through the same application event path used for webhook-driven updates. This keeps the browser protocol stable if you later switch providers.
Recommended Free Tools
- Schedule a status check after the provider accepts the job.
- Stop checking when the job reaches a terminal state or the application’s deadline expires.
- Increase the delay between checks within a defined maximum so a large queue of jobs does not create uncontrolled request volume.
- Record transient lookup failures separately from a provider-reported job failure; retry transient errors within the policy’s bounds.
- Route successful, failed, and unresolved outcomes through the same state validation, persistence, and SSE publishing logic.
The OpenRouter video guidance documents asynchronous jobs with polling. TanStack AI also shows server-side polling forwarded through an SSE response, as an implementation example for that framework rather than a provider-independent contract. A periodic status sweep is useful even with webhooks so unresolved jobs can be reconciled after delivery or application outages.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to reconnect without losing job updates
Reconnection is a transport feature, not a guarantee that the browser has a complete job history. The application must define what recovery means.
- If you retain events: Assign stable IDs, keep a replay log for an appropriate retention period, and resume from the last ID supplied by the client.
- If you retain only current state: On reconnection, send or fetch a current snapshot. This restores the truth about the job but may not reproduce every intermediate status.
- If a job is already terminal: Return its final state promptly and close the stream, or send the final event before closing. Avoid leaving a completed job’s stream open indefinitely.
Do not assume the provider will repeat every intermediate update after a reconnect. The application’s durable state or replay log is the recovery source of truth.
How to choose a provider integration
Before committing to an integration, check the current official documentation for the provider’s API version, event catalog, signature procedure, retry behavior, status lookup, output retrieval, retention, quotas, and pricing. These details can change and are not interchangeable across providers.
Quick Recap
- Notification mechanism: Does the API provide a native webhook, status polling only, or a provider-specific stream?
- Event detail: Are only terminal states documented, or are intermediate progress updates available?
- Delivery semantics: Does the provider retry deliveries? Are they at least once? Is there a stable event or delivery ID for deduplication?
- Security: What signature scheme is used? Are timestamps or replay checks specified? How are secrets rotated and callback URLs constrained?
- Recovery: Can the application retrieve current job status and obtain the output after a missed notification?
- Result handling: Does the callback contain media bytes, or only a pointer to a separately retrieved output? Gemini documents an output file pointer in its video event, while OpenRouter documents retrieving generated video content separately.
- Browser delivery: Does the application need a per-job stream or a multiplexed stream? Is event replay supported?
Implementation checks before launch
- Submitting the same client request twice has a deliberate outcome, and every job has a durable application ID.
- Provider callbacks are authenticated, deduplicated, and constrained to valid state transitions.
- Job state is saved before an SSE event is emitted.
- Streams recover from disconnections using either replay or a current-state snapshot.
- Polling has a deadline and bounded backoff, and unresolved jobs can be reconciled.
- The UI distinguishes queued, running, completed, failed, and unknown or delayed states without inventing progress.
- Generated media is retrieved through the documented result flow rather than assumed to arrive in the SSE stream.
- Connection count, heartbeat behavior, and stream closure are tested through the application’s actual proxy and deployment path.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
