Default queued execution model
Every model endpoint (Text-to-Image, Text-to-Speech, Image-to-Text, Image-to-Image, Video-to-Text, Image-to-Video, Text-to-Video, Text-to-Embedding, etc.) works the same way:- You send a request to:
POST /api/v1/client/{task} - The response returns a
request_id - You check progress and fetch the result via:
GET /api/v1/client/request-status/{job_request}
request-status response includes:
- current job status (e.g.
pending,processing,done,error), - optional progress information,
- result URLs and/or inline output data,
- optional error details when a job fails.
- keeps long-running jobs (image/video generation, transcription) off the critical HTTP path,
- avoids common HTTP timeout issues,
- lets deAPI schedule work efficiently across a distributed GPU network,
- gives you one consistent pattern across all model endpoints.
- Get Results –
GET /api/v1/client/request-status/{job_request} - individual API pages under API (Text-to-Image, Text-to-Speech, etc.).
Future extensions: webhooks and synchronous HTTP
On top of the queue model described above, we plan to add:- Webhooks for queued jobs – instead of polling
request-status, you will be able to provide a webhook URL that deAPI will call when the job finishes. - Additional HTTP modes (e.g. synchronous requests) – for small, low-latency jobs where returning the result in a single HTTP response makes sense.