Latenode webhook trigger: fast mode or default for Sume callbacks?

Leave the Latenode webhook on its default reply for Sume's run callbacks. Sume treats any 2xx within 10 seconds as delivered, and Latenode's default is to accept the request and return 200 OK right away when the scenario has no Webhook Response node. Fast mode also replies immediately, but Latenode warns the sender may not see scenario errors, which removes a signal you may want.

The three Latenode reply modes

Wire it up

Scenario A starts the run. Its HTTP node POSTs to https://api.sume.com/v1/agent/completions with instruction, a required generation_spend_cap_usd, and communication.webhook_url set to scenario B's production URL. Latenode gives a production URL for continuous use and a development URL that runs the scenario once, so register the production one with Sume. Scenario B is the trigger and parses the body.

{
  "instruction": "Write a 20-word caption for the attached product photo",
  "generation_spend_cap_usd": 1,
  "communication": { "webhook_url": "https://YOUR-LATENODE-PRODUCTION-URL" }
}

What to do inside scenario B

Latenode lists POST for data and GET for triggering without a body, and Sume always sends POST, so no method change is needed.

Test once end to end with a low cap such as one dollar before pointing production work at the scenario, and confirm in the dashboard that the delivery row shows a 2xx.

• Branch on outcome, not on status: ok, degraded or error. A degraded run completed but has output: null; read output_error for the reason.
• Dedupe on request_id, which equals the run id and is stable across retries.
• If payload is null, fetch result_url; Sume nulls payloads over 1 MiB.
• Verify x-sume-webhook-signature before trusting the body. A webhook URL is easy to leak in logs, so the signature adds a second check.

Why not fast mode here

Fast mode is useful when a sender has a very short timeout. Sume's budget is ten seconds, which the default reply meets with room to spare. Fast mode's cost is lost visibility: if your parsing fails after the reply, Sume records a successful delivery and will not retry. With the default reply you get the same quick acknowledgement and keep the option of failing the scenario later through a separate alert.

Latenode also exposes __ln.resp.body, __ln.resp.status and __ln.resp.header.<header> parameters for shaping the reply from the URL itself. You do not need them for Sume. Sume's documented success rule is any 2xx, so a bare acknowledgement is enough and keeps the scenario simple.