Jotform webhook rawRequest and a 30 s timeout: start a Sume run
Jotform posts submissions as form data with a rawRequest field and a 30 s timeout. Answer fast, start a Sume Format run, and let a webhook return the result.

A Jotform webhook can start a Sume Format run directly, as long as your endpoint answers inside Jotform's 30-second request timeout and parses the submission correctly. Jotform sends the form data with a rawRequest field that holds the submission as JSON, so the endpoint reads the form field, decodes it, and then calls POST /v1/formats/{handle}/{slug}/runs, which returns a 202 receipt in moments.
The timeout is generous for a create call and hopeless for the media itself, so the design is: answer Jotform immediately, let the run take its minutes, and receive the result through a Sume webhook.
What Jotform documents
Jotform's webhook setup page shows a PHP example that reads rawRequest from the request and decodes it as JSON, which indicates form-encoded delivery rather than a plain JSON body (read 2026-10-10). It says you can add more endpoints with Add New Webhook, that the Webhooks integration has a 30-second request timeout, and that an encrypted form can send only encrypted data through the webhook.
The page does not state retry attempts, intervals or delivery guarantees, so treat a failed call as possibly lost.
| Topic | Jotform | Sume |
|---|---|---|
| Payload shape | Form data with a rawRequest JSON field | JSON body, at most 4 MiB; input at most 2 MiB |
| Time budget | 30-second request timeout | POST ...runs returns a 202 receipt; the run itself takes minutes |
| Several destinations | Add New Webhook for more endpoints | One communication.webhook_url per run |
| Retries | Not stated on the page | Create is safe to repeat with the same Idempotency-Key |
| Encrypted forms | Only encrypted data can be sent | Decrypt before you pass fields to input |
Do not hold the request open
Sume has a bounded wait for generation jobs: mode: "sync" holds the submit call for at most 30 seconds, equal to Jotform's whole budget, and a job that is not terminal then must be polled, not resubmitted. A Format run has no such mode. Its communication.mode is async or webhook, and the create answer is a receipt.
So the Jotform handler should do three things only: decode rawRequest, create the run, and return 200. Everything slow happens after the response.
Map fields to the run
Pass the answers a person gave as input fields such as product name, tone and a photo URL, and keep decisions in instruction. Media URLs in input must be public HTTPS and share a budget of 30 attachments, at most 30 images, 10 videos and 10 audio files. Treat form text as untrusted data: Sume tells the agent that input is caller data, not instructions, but a spend cap is still your real limit.
Derive Idempotency-Key from the submission identifier your payload carries plus a version. If Jotform or your own queue repeats the call, Sume returns the original receipt with idempotency_hit: true instead of a second run.
Send the result by email or sheet
Set communication.webhook_url to your own route. On the format.run.terminal event, verify x-sume-webhook-signature, dedupe on request_id, and branch on outcome. Then email the media URL or write it to a sheet with your own code. Media URLs are durable media.sume.com HTTPS links that anyone with the URL can open, so proxy them if the output is private.
Watch the failure shapes on the create call. 402 insufficient_credits means the workspace cannot fund the run, so stop and alert rather than retry. 429 rate_limited carries retry-after, and 503 is a Sume-side outage that is safe to retry with the same key. Because Jotform's page gives no retry guarantee, log every submission you could not turn into a run, so a person can resend it later.
Add generation_spend_cap_usd on every create. Public forms invite spam, and the cap bounds what one submission can spend; the platform maximum is $500 per run.
Sources
Related posts
More in Integrations
- Render deploy hook returns 202: start a Sume run after a deploy
Render deploy hooks return 200 when a deploy starts and 202 when queued. Call one, then start a Sume Format run for the release only once it ships.
- SendGrid ECDSA event webhook vs a Sume HMAC verifier: two checks
SendGrid signs event webhooks with ECDSA, while Sume uses HMAC SHA256. Here is why one verifier will not cover both and how to start a Sume run from an event.
- Smartsheet webhook verification challenge, then a Sume Format run
Smartsheet checks your endpoint with a challenge before a webhook is enabled. Answer it, then use change events to start Sume Format runs with a stable key.
- ClickUp taskStatusUpdated webhook: start a Sume Format run
Start a Sume Format run when a ClickUp task changes status: verify X-Signature, derive the Idempotency-Key from the task, cap spend, and write the result back.
Written by Sume