Synthesia needs a Legacy (v2) key; Sume keys carry scopes per call

Synthesia's quickstart says video API requests need a Legacy (v2)-scoped key, not an Interactive Avatars-scoped one. Pick the wrong key type and the call can fail for a reason that is a product mix-up rather than a code bug. Sume has no such split: you send a bearer key, and its scopes decide what that key may do. Format calls, for example, need formats:write to create a run and formats:read to read one.

Synthesia source: API quickstart, read 2026-10-04. Sume source: Calling a Format.

The two models side by side

Synthesia ties the key to a product scope. Sume ties it to operations. In both cases the cure for a mysterious 401 or 403 is the same: check which key your server is actually sending.

Debugging a rejected key on Sume

Check three things in order. First, the workspace: Sume keys are workspace-scoped, so confirm the key belongs to the workspace you expect. Second, the header: send one credential, not two. Third, the scope: a service-account key cannot create Format runs at all, per the Format docs, and a read-only key cannot start one.

• Log which workspace the key belongs to.
• Log only the last four characters of a key.
• Create separate keys per environment and name the variable by host, not by prefix.

Keep keys server-side

Never place either vendor's key in client code. For browser products, add an endpoint of your own that calls the vendor and returns only the job id or the finished URL. That endpoint is also the place to cap spend per customer, using generation_spend_cap_usd on a Format run.

Bottom line

If you are migrating from Synthesia, drop the idea of a per-product key and give each service its own Sume key with only the scopes it needs. The authentication page covers creating them.