Jotform Webhook MCP Server

Jotform Webhook

Each stored delivery is one Jotform form submission — a multipart POST normalized to JSON on ingest. Tools read what already landed; there is no pull API and no way to submit, edit, or replay submissions from here.

Jotform payload shape (export.json)

Jotform POSTs multipart/form-data (not a bare JSON body). Ingest merges the form fields into one object and JSON-parses rawRequest so answers are walkable in export.json.

Top-level metadata (always inspect these first):

• formID — numeric id of the form that received the submission.
• submissionID — unique submission id; prefer this when deduping across deliveries.
• type — submission origin (for example WEB for a standard web submit).
• formTitle — human-readable form name when Jotform includes it.
• ip — respondent IP address when present.
• pretty — optional human-readable summary string on some payloads; prefer parsed answers over this when both exist.
• rawRequest — parsed object of submitted answers (ingest decodes the JSON string Jotform sends).

Walking answers in rawRequest

Keys follow Jotform question identifiers: q{number}_{slug} (for example q3_name, q4_email, q15_yourMessage). The number is the field id in the form builder; the suffix is a slugified label. Ids can change when fields are reordered or recreated — inspect the latest delivery for this connection rather than hard-coding keys.

Each rawRequest entry value shape depends on field type:

• Single-line text, email, textarea, dropdown (single) — string.
• Full name — object with first, last, optional middle; join for display.
• Address — object with addr_line1, addr_line2, city, state, postal, country (only present sub-keys appear).
• Phone — string or structured object depending on the widget.
• Multiple choice / checkboxes — array of selected values, or occasionally a comma-separated string in legacy payloads; normalize before quoting.
• File upload — URL string pointing at Jotform-hosted file storage (not embedded bytes).
• Signature, payment, matrix, and widget fields — nested objects or arrays; read the value as stored rather than assuming a flat string.

Field ids and slugs vary per form — map answers from the latest export.json, not from a fixed lead schema.

First moves

1. Latest report — default for “what did the last respondent submit”.
2. Read metadata — note formID, submissionID, type, and ip before walking rawRequest.
3. Walk rawRequest keys — for each qN_* key, show the slug suffix and resolved value (expand name/address objects into readable text).
4. Recent reports — list when comparing volume, duplicate submissionID values, or submissions from a date range.
5. One report by id — after listing, when the user points at a specific delivery.

Stored response shape

• export.json — normalized webhook object with parsed rawRequest (preferred for answer-level questions).
• export.text — raw body when JSON is large or parsing fell back.
• source.captured_at — when the POST landed here (not necessarily the upstream submission timestamp).

Operational order

1. Start with the latest report — do not guess a report id.
2. Confirm submissionID before treating two deliveries as duplicates.
3. Walk rawRequest keys for field-level answers — do not expect friendly labels at the top level.
4. List recent reports only for history, duplicate suspicion, or explicit compare-by-date asks.
5. Read ## This connection in the skill supplement for form-specific field id notes.

Gotchas

• Read-only — cannot submit forms, edit responses, or trigger webhooks from here.
• Multipart upstream — Jotform sends form-encoded parts; ingest stores one merged JSON object per submission.
• rawRequest is the answer map — metadata lives alongside it at the top level, not inside rawRequest.
• Variable forms — each connection may receive a different form; **qN_* keys differ per form design.
• Field id drift — reordering or replacing questions in the form builder can change **qN_* ids; re-check after form edits.
• No aggressive retries — Jotform does not retry failed webhooks reliably; a missed delivery will not appear later.
• File uploads are URLs — quote filenames or links from the stored value; binary content is not inlined.
• Encrypted forms — when the upstream form is encrypted, webhook data arrives encrypted and cannot be interpreted here without upstream decryption.
• Empty — no stored reports means nothing has arrived yet; say no submission is available.