Node-RED http request node: submit a Sume job and branch on statusCode

The answer

Node-RED's http request node sends the request described by msg.url, msg.method, msg.headers and msg.payload, and puts the response body in msg.payload with msg.statusCode and msg.headers beside it. For a Sume submit, set method to POST, send a JSON payload with mode: async, and branch on msg.statusCode before reading the job id from the body.

The node help also says it can parse the body as JSON and that the status code field holds the error code if the request could not be completed, so a check on that field covers both HTTP errors and network failures.

What the node reads and writes

These are the properties from the node's own help text that matter for a Sume call.

Build the message

A function node ahead of the request builds the message. Keep the Idempotency-Key derived from your own record id so a replayed flow sends the same key.

msg.url = "https://api.sume.com/v1/images";
msg.method = "POST";
msg.headers = {
  "content-type": "application/json",
  "idempotency-key": "order-" + msg.orderId + "-r1",
};
msg.payload = {
  model: "sume/auto",
  mode: "async",
  prompt: msg.prompt,
};
return msg;

Branch and keep the id

Sume documents 202 or 200 for an accepted submit, then 401, 402, 429 and 5xx for the failures. A switch node on msg.statusCode can send accepted responses on and everything else to an alert. On the accepted branch, the job id is in the parsed body under data.request_id; store it in flow context along with the order id.

The status read is a second http request node with method GET and the url https://api.sume.com/v1/jobs/<id>/status. Poll on the terminal boolean and the next_poll_after_seconds hint; fetch the result only when result_ready is true.

Where the key goes

The Authorization header is the next post's subject, because Node-RED's help text sets a precedence rule between the node configuration and msg.headers that decides where the key belongs. Read it before you put a credential in a message.

Timeouts and the 30-second wait

The node help says requestTimeout, in milliseconds, overrides the globally configured HTTP request timeout. Sume's server-side sync wait is clamped to 30 seconds and bounds how long the request blocks, not how long the job runs. With async submits the call returns quickly, so a timeout of ten to fifteen seconds on the submit node is plenty, and the long wait lives in your polling flow instead.

If a submit times out on your side, the job may still have been created. Resend with the same Idempotency-Key and the same payload; Sume returns the original job instead of billing again. A different key creates a second paid job.

Polling inside a flow

A common layout is an inject node on a timer feeding a function node that reads the stored job ids from context, then an http request node for each status read. Use the next_poll_after_seconds value from the previous response to decide whether to skip a tick. When terminal is true, route the message to a result-fetch node if result_ready is true, and to an error branch otherwise.

Keep the total deadline on your side. Sume's docs suggest around twenty minutes for video as a reasonable client-side limit, and note that giving up does not cancel the job; cancel explicitly while it is cancelable if you want it to stop.