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.

4 min readSume
All posts

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.

Execution Data node facts from n8n's page, read 2026-10-02.
ItemWhat the page says
OperationSave Execution Data for Search
KeyLimited to 50 characters
ValueLimited to 512 characters
Over the limitTruncated to the maximum, with a log entry
n8n CloudPro and Enterprise
Self-hostedRegistered 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

All Integrations posts

Written by Sume