Runware deliveryMethod async vs Sume mode async: map the fields

If your code already speaks Runware's async video flow, the move to Sume is a rename of three things. Runware's page (read 2026-10-07) says deliveryMethod: "async" queues the task and returns a taskUUID at once, that you can poll getResponse, or pass a webhookURL to have the result posted to you. Sume's job API has the same three pieces: a job id on submit, a status poll, and a webhook mode.

What differs is the contract details: Sume's job ids start job_, status is read from GET /v1/jobs/:id/status, and webhooks are terminal-only and signed.

Field mapping

Only the left column is Runware's wording, taken from its page; the right column is from the Sume docs.

What you must add on the Sume side

Three habits are not optional. First, send an Idempotency-Key on every paid submit, so a retry after a network error returns the original job instead of billing a second one. Second, verify the x-sume-webhook-signature header against the raw body before you trust a callback. Third, keep polling as a backstop: a webhook is a delivery optimization, and after ten failed attempts you still have a finished job that never told you.

Webhook URLs must be public HTTPS; Sume rejects localhost, private-network and non-HTTPS URLs.

A submit with a callback

This is the Sume side of the mapping: one POST to /v1/videos with an idempotency key and a callback_url. The response gives you the job id and a polling_url to store.

curl -X POST "https://api.sume.com/v1/videos" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: clip-8823-v1" \
  -d '{
    "model": "seedance-2",
    "prompt": "Slow push-in on a ceramic mug on a wooden table",
    "callback_url": "https://example.com/hooks/sume"
  }'

What not to port

Do not port a progress bar that depends on intermediate webhook events; Sume sends none. There is no SSE or WebSocket stream on the Developer API, and GET /v1/jobs/:id/events is a snapshot you pull. Show queued, processing and done, which are the states the API actually has.

Migration checklist

Porting a Runware async integration to Sume is mostly bookkeeping. Walk this list once and run it against a single cheap request before you move traffic.

Sume rejects unknown parameters with 400 unsupported_parameter rather than dropping them silently, so a request body copied from another vendor fails loudly on the first call, which is the behavior you want during a port.

• Replace the task identifier column in your database with the Sume job id, and add status_url and result_url beside it.
• Pick async plus polling for work that can last longer than 30 seconds; sync and subscribe are only a bounded wait of at most 30 seconds.
• Register a public HTTPS callback, and verify the signature on the raw body.
• Keep the poll loop as the backup path, with exponential backoff and a client-side deadline.
• Send a fresh Idempotency-Key per logical request, and reuse it only for an exact retry.