Skip to main content
The unified async task API provides a standardized submit → poll → retrieve workflow, abstracting away provider-specific differences.

Overview

AI tasks such as video generation, image generation, and music generation can take anywhere from tens of seconds to several minutes. To ensure a good user experience and system stability, these tasks are handled through an async task API:
  1. Submit a task — Send a generation request and immediately receive a task ID
  2. Poll for status — Use the task ID to check progress, or receive a callback notification
  3. Retrieve results — Once complete, get the generated resource URLs from the response

Submit a Task

POST /v1/task/submit

Request Parameters

Request Examples

Response Example


Query a Task

GET /v1/task/{task_id}

Request Examples

Response Examples

Task in progress:
Task completed (token-based billing):
Task completed (duration-based billing):
Task failed:

Task Statuses


Callback Notifications

When you include a callback_url in your submit request, the system will send a POST request to that URL whenever the task status changes. The callback body uses the same format as the query response:
  1. The callback URL must be publicly accessible over HTTPS
  2. Callback requests have a 10-second timeout
  3. Callback URLs cannot point to localhost, 127.0.0.1, or the platform’s own domain
  4. Even with callbacks enabled, implement polling as a fallback to avoid missing notifications due to network issues

Complete Polling Example


Response Fields


Usage Information

After a task reaches a terminal state (completed / failed), some models include a usage field in the response that reports the actual resources consumed. The usage field is a tagged union: the type field distinguishes the metering unit.

type=tokens (token-based billing)

Used by Doubao / Vidu / Ali / Kling text-based / Gemini and other token-billed tasks:

type=duration (duration-based billing)

Used by Sora / Xai-video and other video generation tasks billed by output duration:
  • Tasks billed strictly per-call (e.g., Flux / Replicate / Midjourney) do not return a usage field
  • The usage field is not returned while the task is queued or in_progress
  • Historical tasks and tasks where the upstream did not report usage data also omit this field
  • Sub-fields with a zero value (e.g., text_tokens: 0) are omitted

Flux models and webhook_url limitations

Some BFL tool endpoints (e.g. flux-tools/outpainting-v1) declare additionalProperties: false in their official Inputs schema and do not accept webhook_url / webhook_secret. Sending those fields in input causes upstream BFL to return:
Gateway behavior:
  • Webhook-capable Flux models (e.g. flux-dev): the gateway injects its callback URL and enables priority callback polling
  • flux-tools/outpainting-v1: the gateway strips webhook_url / webhook_secret automatically — use polling instead
Correct usage for flux-tools/outpainting-v1: Do not pass webhook fields on submit; poll GET /v1/task/{task_id} after submission (recommended interval 3–10 seconds).
If BFL adds more tool endpoints that reject webhooks, register them in the gateway BFLNoWebhookModels blacklist. Currently only flux-tools/outpainting-v1 is listed.

Notes

  1. Authentication uses standard Authorization: Bearer <API_KEY> headers
  2. The input parameters vary by model — click on the model in the Models page to view its documentation
  3. Recommended polling interval is 3–10 seconds to avoid excessive requests
  4. Resource URLs in task results may have expiration limits — download and save promptly
  5. Do not use webhook_url for Flux tool models such as outpainting — see “Flux models and webhook_url limitations” above

Video Models

Provider-specific video generation API documentation

Image Models

Image generation API documentation