Vidu's payload pass-through vs Sume: where to keep your order id

Vidu's image-to-video request has a payload field described as a pass-through parameter, sent back without processing, up to 1,048,576 characters. Sume's /v1/videos request table has no such field, and a non-empty provider.options returns 400. Keep your own order id in your database, tied to the Sume job id, and use an Idempotency-Key built from the order id so a retry never makes a second paid job.

What does each side offer?

Here is how each side handles your own data and retries.

How do you tie an order to a job?

Write the order and its key first, then submit. If the process dies after the POST, run the same order again: the same key returns the same job. The sketch uses SQLite and a fake sender so it runs as is.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("create table jobs(order_id text primary key, idem text, job_id text)")

def submit(order_id, send):
    row = db.execute("select idem from jobs where order_id=?", (order_id,)).fetchone()
    idem = row[0] if row else "order-" + order_id
    if not row:
        db.execute("insert into jobs(order_id, idem) values (?, ?)", (order_id, idem))
    job_id = send(idem)  # POST /v1/videos with Idempotency-Key: idem
    db.execute("update jobs set job_id=? where order_id=?", (job_id, order_id))
    db.commit()
    return job_id

fake = lambda key: "job_" + key
print(submit("A17", fake), submit("A17", fake))

What if you only have the job id?

Sume jobs can be read at GET /v1/jobs/{id}/status as well as at the polling URL, so a table of job ids is enough to resume. A key reads only the jobs its own member created in its workspace, so keep one key per worker pool.

Use the order id, not a random value, as the key seed: the whole point is that a restart derives the same key.