Once a job is submitted, Yoink pushes real-time status updates to the client using Server-Sent Events (SSE). This is a unidirectional HTTP stream: the client opens a persistentDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/coah80/yoink/llms.txt
Use this file to discover all available pages before exploring further.
GET connection and the server writes newline-delimited data: frames as the job progresses. No WebSocket upgrade or polling is required.
Three endpoints work together to give you full control over a running job:
| Method | Path | Purpose |
|---|---|---|
GET | /api/progress/{id} | Open SSE stream for a job |
POST | /api/cancel/{id} | Cancel a running job |
POST | /api/finish-early/{id} | Stop a playlist download and package what has been downloaded so far |
GET /api/progress/
Opens an SSE stream for the given job ID. The connection stays open until the job reaches a terminal stage (complete, error, cancelled, or finishing-early) or the client disconnects.
Response headers
The job ID returned by the endpoint that started the download, conversion, or compression job.
Keep-Alive Pings
The server sends a keep-alive comment frame every 15 seconds when no progress event has been written. This prevents proxies and load balancers from closing the idle connection:Event Frame Format
Each event is a singledata: line containing a JSON object, followed by a blank line:
Event Payload Schema
Every event object contains at leaststage and message. The remaining fields are present only when relevant to the current stage.
The current lifecycle stage of the job. See Stage Reference for all possible values.
A human-readable description of what is happening. Suitable for display directly in a progress UI.
Completion percentage as a float from
0 to 100. Present during downloading, processing, compressing, zipping, and similar active stages. Omitted for instantaneous stages like starting or complete.Current transfer or processing speed, e.g.
"5.2MiB/s". Present during active download stages when the underlying tool reports it.Estimated time remaining, e.g.
"00:12" (mm:ss). Present alongside speed when available.Stage Reference
Example events for each stageReconnection
If the client disconnects mid-job (e.g. due to a network blip) and reconnects to the sameGET /api/progress/{id} URL, the server checks whether the job is still in progress. If it is, the first event sent to the reconnected client is a resuming event carrying the last recorded progress value:
EventSource API’s built-in reconnection logic without losing track of progress.
Reconnection only works while the job is still running on the server. If the job completed or was cancelled while the client was disconnected, opening the progress stream will receive no further events (or may receive the terminal event immediately if it is still buffered).
POST /api/cancel/
Cancels a running job, kills the underlying process, cleans up temporary files, and emits acancelled event on the progress stream.
Path Parameters
The job ID to cancel.
The
clientId of the session that owns the job. If provided and the job is owned by a different client, the server returns 403. If omitted, ownership is not checked.200 OK — job was found and cancelled
200 OK — job not found (already complete or never existed)
403 Forbidden — caller is not the job owner
POST /api/finish-early/
Signals a playlist job to stop downloading new videos and immediately package whatever has been downloaded so far into a ZIP archive. The job transitions to thefinishing-early stage and then to complete once zipping is done. This is useful when the user wants only the first N videos from a large playlist.
Path Parameters
The playlist job ID to finish early.
The
clientId of the session that owns the job. Returns 403 if the caller is not the owner.200 OK
403 Forbidden
JavaScript Example
The following snippet demonstrates a full SSE integration: opening the stream, handling each stage, reconnecting automatically, and wiring up cancel/finish-early controls.The browser’s
EventSource API reconnects automatically when the connection drops. Because Yoink sends a resuming event on reconnect, your handler will re-sync the progress bar to the correct value without any extra bookkeeping.