n8n Execution Data node: find a run by its Sume job id
Save the Sume job id with n8n's Execution Data node and you can search the Executions list by it. Keys cap at 50 characters, values at 512, plan limits apply.

Add an Execution Data node right after the Sume submit step, with a Saved Field such as sume_job_id set to the job id from the response. n8n then lets you search the Executions list by that metadata, so a support question like 'what happened to job X' becomes one search instead of opening runs one by one. Keys are limited to 50 characters and values to 512, and n8n truncates anything longer.
The node's behavior is from n8n's Execution Data page (read 2026-10-02); the job id from Sume's Jobs and results.
What does the node store, and who can use it?
It saves key and value metadata for a workflow execution, searchable in the Executions list, and a Code node can read the saved values during the run. n8n lists plan availability, so check yours before you build on it.
| Item | What the page says |
|---|---|
| Operation | Save Execution Data for Search |
| Key | Limited to 50 characters |
| Value | Limited to 512 characters |
| Over the limit | Truncated to the maximum, with a log entry |
| n8n Cloud | Pro and Enterprise |
| Self-hosted | Registered Community and Enterprise |
Which Sume values are worth saving?
The job id (request_id in the submit response, job_id in the webhook) and the Idempotency-Key you sent. Both fit well inside 512 characters, since Sume allows up to 255 characters in the key. Save them under fixed key names so searches stay consistent across workflows, and add your own record id.
Where do I put the node in the flow?
After the submit, because the job id only exists once Sume has accepted the job. If the same execution resumes later through a Wait node, or a second workflow handles the webhook, call the node again there with the same key name, so the terminal run is findable by the same id. Sume's docs say to treat job_id as the idempotency key on your side; the saved field is where you look it up.
How does this help when a job fails?
Search the failed run by job id, then read the job itself: GET /v1/jobs/{id} returns the public error with a category and next action, and GET /v1/jobs/{id}/events returns the timeline, including webhook.delivery. That tells you whether the job failed or only the delivery did. A failed delivery with a completed job is fixed by POST /v1/jobs/{job_id}/webhook/redeliver, not by a new submit.
Pair this with an error workflow so failures arrive with the id already attached.
Sources
Related posts
More in Integrations
- n8n Form Trigger: Respond When and a long Sume video job
n8n's Form Trigger can answer on submit or when the workflow finishes. For a Sume video job that runs minutes, answer on submit and deliver the video later.
- n8n payload limit 16 MiB: pass Sume artifact URLs, not video bytes
n8n caps webhook payloads at 16 MiB and form-data files at 200 MiB. A Sume callback is small JSON with media URLs, so keep the video out of the payload.
- n8n Remove Duplicates node: skip repeat rows before Sume calls
Use n8n's Remove Duplicates node in previous-executions mode so a repeated row never reaches a paid Sume call, and keep an Idempotency-Key for retries.
- n8n WEBHOOK_URL deprecated in 2.35: the URL Sume will accept
n8n 2.35.0 deprecates WEBHOOK_URL for N8N_WEBHOOK_URL. Sume only calls public HTTPS webhook URLs, so a wrong base URL fails at submit. How to set and test it.
Written by Sume