Activepieces HTTP GET with a body: poll Sume status instead

An Activepieces HTTP step that polls Sume should be a GET with no body: the job id goes in the path, as in GET /v1/jobs/:id/status, and the API key goes in a header. Sume's polling endpoints do not read a request body, so nothing is lost when the body field disappears.

Activepieces 0.91.0 (2026-09-14) lists "hide body input for GET/HEAD requests (#15398)" and several pieces moved params out of the GET body, including ConvertKit's api_secret to the query string. Sume side: Jobs and results, read 2026-10-01.

Why did Activepieces hide the GET body?

The release notes name the cause in one entry: a MoonInvoice dropdown sent filters as a GET body, which is dropped. Moving those params to the query string or path is the pattern the other entries follow (ConvertKit, Talkable, TrueLayer). The release notes do not say more than that, so check your own flows for a GET step that still carries JSON.

What does a Sume status poll look like?

The docs example is a bare curl to the status URL with the key in Authorization. Stop polling on completed, failed or canceled, use exponential backoff, and do not resubmit the original paid request just because a local process timed out.

curl https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"

Which Sume calls are reads and which are writes?

Sume counts any GET or HEAD as a read, with its own per-minute budget separate from writes, so a tight poll loop cannot 429 your own submits.

What should the Activepieces step do on a 429?

Read retry-after when present and wait. A 429 on a status poll is read backpressure, not generation concurrency. See Activepieces sync webhook 408: use Sume async mode for the submit side.