Basin Webhook MCP Server

Basin Webhook

Basin POSTs a webhook when a form receives a submission. Each POST is one stored report. The JSON shape depends on the payload format chosen upstream — flat JSON, data-wrapped JSON, urlencoded-as-string, vendor presets (Customer.io, MailerLite, Pardot), or a custom Handlebars template. Field names mirror the form schema plus Basin metadata; there is no fixed column layout across connections. Tools read what already landed — there is no pull API and no way to re-fire or mutate submissions from here.

First moves

1. Latest report — default for “what was submitted last” or lead triage.
2. Recent reports — scan history for volume, duplicates, or a named submitter.
3. One report by id — after listing, when the user points at a specific delivery.
4. Inspect export.json — read the parsed body; fall back to export.text when the payload is large or non-object.

Typical payload shapes

Flat JSON — form fields at the top level alongside Basin ids:

• email, name — common when those fields exist on the form.
• id — Basin submission id; use for deduping against re-fired webhooks.
• attachments — array of uploads with public_url and attachment_proxy_url; custom templates may also expose name and file_size.

Data-wrapped JSON — the same fields nested under a top-level data object. Unwrap data before reading field values.

Urlencoded / Pardot-style — body may arrive as a data string of key=value&… pairs rather than nested JSON keys.

Custom templates — upstream may add merge-tag fields such as form-name, dynamic keys from form_params, source tracking (source_host, source_path, source_query, source_fragment), and optional lead_agent scoring (score, score_reasoning, score_location_info). Treat every custom key as form-specific.

Response shape

• export.json — parsed object when the body was JSON.
• export.text — raw body for urlencoded strings, custom content types, or oversized payloads.
• source.captured_at — when the webhook landed here (not necessarily the upstream submission timestamp — check id or any timestamp fields inside the JSON).

Operational order

1. Start with the latest report — do not guess a report id.
2. If captured_at is older than expected, say so — Basin sends when submissions arrive, and upstream may retry failed deliveries.
3. List recent reports only for history, duplicate suspicion, or explicit compare-by-date asks.
4. Read ## This connection in the skill supplement for form-specific field names or payload-format notes.

Gotchas

• Read-only — cannot submit forms, acknowledge Basin, or trigger re-fires from here.
• Payload format varies — the same form may use flat JSON, a data wrapper, or a custom template; inspect the latest delivery instead of assuming keys.
• Spam filtering — upstream may skip webhooks for spam-flagged submissions unless the form owner enabled webhooks for all submissions; an empty stretch may mean filtering upstream, not ingest failure.
• Re-fires and retries — Basin retries failed webhooks and supports manual re-fires; the same id can appear more than once — compare source.captured_at when deduping.
• Attachments — file metadata lives in attachments; binary bytes are not inlined — cite URLs from the JSON when the user asks about uploads.
• Empty — no stored reports means nothing has arrived yet; say no submission is available.