Queues, limits and retries

H3 video task API · /api/v3

Queues and concurrency

Rule	Behavior
Concurrency / submission RPM / queue size	Counted per customer account and model; keys in the same account share limits.
Read limits	Retrieve: 20 QPS; list: 1 QPS; cancel/delete: 20 QPS. Each limit is shared across the account.
Scheduling order	Accounts are served fairly in rotation. Tasks waiting over 300 seconds receive protection, followed by priority and creation order. Inference is not preempted.
Capacity and queues	Requests for verified presets enter a durable queue and wait while a GPU is busy or temporarily offline. A long estimated wait alone does not cause rejection. Explicit account submission limits, queue limits and platform safety limits can return 429.

Administrators configure concurrency and queue limits. New accounts default to 200 queued tasks and 180 submissions per minute. Queue estimates are not completion-time guarantees. Multiple keys cannot bypass account limits.

Safe retries

HTTP header · Reuse for retries of the same task

Idempotency-Key: customer-video-20261102-001

The same account, key and request return the original task without accepting it twice. Reusing a key with a different request returns 409. Use a new key for each new task.

For 429 / 503, follow Retry-Afterand use exponential backoff with jitter. Retry failed reads as reads only. If creation times out, retry the same request with its original idempotency key instead of creating a second task.

Expiry and notifications

Time / notification	Description
Task lifetime	Starts at acceptance and includes queueing. Default: 172800 seconds; configurable from 3600 to 259200 seconds, subject to the platform limit.
Video link	Valid for a fixed hour after completion and delivery readiness. Queries do not renew it; an expired successful task may return a null URL.
Task records	7 days from creation; cancelled records are retained for 24 hours.
HTTPS callbacks	callback_url receives queued, running and terminal snapshots. Intermediate states are attempted once; terminal states up to three times. A 2xx response acknowledges delivery.

Callbacks can be duplicated or arrive out of order. Deduplicate by task ID and terminal state, using retrieval as the authority. Persist the event and return 2xx promptly, then process it asynchronously. The platform never requires an API key in the callback URL.

Receive task-completion callbacks

JSON · Add this field when creating a task

{
  "callback_url": "https://YOUR_APP_HOST/webhooks/fablun"
}

The body has the same structure as a single-task response. On success, read the video URL from content.video_url . Callback timeout is 5 seconds. Failed terminal deliveries retry after approximately 5 and 15 seconds, at most 3 attempts including the first. Delivery failure neither cancels generation nor charges again.

Request headers	Purpose
X-Fablun-Timestamp	Signature timestamp in seconds
X-Fablun-Signature	sha256= followed by the hexadecimal HMAC-SHA256 signature
X-Fablun-Event-ID	Stable event ID for receiver-side deduplication

The signed message is timestamp + "." + raw request body. Use the account's callback signing secret, constant-time comparison and timestamp validation (a 5-minute window is recommended). Only the account owner can read the secret. Update the receiver after an administrator resets it. Legacy X-Nabit-Timestamp, X-Nabit-Signature and X-Ravenzet-Event-ID headers remain for compatibility; new integrations should use X-Fablun headers. Find the secret under My organization → Task callbacks.