Storage by Zapier 32-character keys: remember a Sume job id

To remember which Sume job belongs to which record in a Zap, use Storage by Zapier's Set Value with your own short record id as the Key and the Sume job id as the Value, then Get Value in the Zap that receives the webhook. Zapier's page limits keys to 32 characters and 500 keys per Storage account, and says Storage deletes keys after 2 months of inactivity, so do not use Sume's Idempotency-Key (up to 255 characters) as the Storage key, and do not treat Storage as a permanent ledger.

Zapier's limits are from its Storage by Zapier help page (read 2026-10-02); Sume's from Jobs and results and the API reference.

What are Storage by Zapier's limits?

The page lists them under Limitations; the Secrets row matters if you use a Code step with a StoreClient.

How do I wire it across two Zaps?

Zap 1 submits the job. After the Sume call, add a Set Value step: Key is the record id, Value is the job id from the response's request_id. Zap 2 starts from a Catch Hook that receives the Sume webhook, verifies it, then runs Get Value with the record id. Because the webhook carries job_id, you can also look it up the other way: set a second key from the job id to the record id, if both fit in 32 characters. Sume tells receivers to treat job_id as the idempotency key on their side, so check Get Value before you act, and skip the event if the record is already marked done.

What if a key has expired or the store is full?

Sume does not depend on your store. Every job keeps its terminal state, and GET /v1/jobs lists jobs newest first, 100 per page, with the idempotency_key each was created with. If you set that key to something derived from your record id, you can rebuild a lost mapping by listing jobs and matching on it. See reconciling no-code runs with the jobs list.

For a webhook that arrives after the Zap was off, Sume retries up to 10 times at a fixed spacing, and POST /v1/jobs/{job_id}/webhook/redeliver re-sends the real terminal event on demand.

Should the value be the whole result?

No. Store the job id and read the result when you need it: GET /v1/jobs/{id}/result once result_ready is true. Sume artifacts are public media.sume.com URLs, and Sume's docs say to store the Sume URL rather than provider URLs. Keeping only ids also keeps you well under the value limit and the 500-key ceiling when you remove a key as soon as its job is delivered.