BFL polling_url on api.bfl.ai vs Sume status_url

On BFL's global endpoint api.bfl.ai and its EU and US regional endpoints, you must poll the polling_url returned in the first response rather than a URL you assemble. Sume works the same way in spirit: the job envelope carries status_url, result_url, events_url and cancel_url, and you continue with GET status_url.

Sources: BFL's integration guide and Sume's Jobs and results, read 2026-10-01.

What does BFL require?

The guide says that with the primary global endpoint or the regional endpoints you "must" use the polling_url returned in the initial request response. Its example submits a request, reads polling_url from the JSON, and polls that address with your key in an x-key header.

What does Sume return instead?

Every Sume submit mode returns the job id in its first response. The envelope carries status_url, result_url, events_url, cancel_url and, for a bounded wait, a sync object. When a sync wait ends before a terminal state, the docs say you "must" continue with GET status_url, honoring next_poll_after_seconds when present and backing off otherwise.

Do not submit a new paid job for the same intent. A retry of the submit itself is fine with the same Idempotency-Key; see idempotency keys.

How do the two compare?

What should my client do?

Store the URL fields from the first response next to the job id and poll them as given. If you lose them, GET /v1/jobs/{id}/status is the documented status path for a Sume job id. Once terminal is true and sume_status is completed, fetch the result; for failed or canceled, read the error off the job record.