mailinapp
Documentation menu

Zapier & CRM automation

MailInApp doesn't have an official Zapier app yet, but you don't need one: the project webhook is already plain, signed JSON over HTTPS — exactly what Zapier's generic Webhooks by Zapier trigger expects. Point it at any Zap and every interaction — poll vote, form submit, quiz result, product purchase — lands in your CRM, a spreadsheet, Slack, or anywhere else Zapier can reach, with no code.

The same approach works for Make, n8n, Pipedream, or any other automation tool that can catch an inbound webhook — this guide uses Zapier since it's the most commonly requested.

Set it up

  1. In Zapier, create a new Zap and choose Webhooks by Zapier as the trigger app, with event Catch Hook.
  2. Zapier gives you a unique Catch Hook URL — copy it.
  3. In MailInApp, open Dashboard → your email → Responses, paste that URL into the Webhook field, and click Enable.
  4. Copy the signing secret MailInApp shows you (whsec_…) — you'll only see it once. You don't need it for the simplest Zaps, but keep it somewhere safe if you plan to verify signatures later.
  5. Trigger a real interaction — vote on a poll, submit a form, or use the project's test send — then click Test trigger back in Zapier. It should show the payload MailInApp just sent, with fields like event.action, event.value, and recipient.row.
  6. Add whatever action step you want — "Create row in Google Sheets," "Create record in HubSpot/Salesforce/Airtable," "Send Slack message," and so on — mapping the fields you need from the caught payload.
  7. Turn the Zap on.

That's it — every future interaction on that project flows through automatically. Every field available for mapping is documented on the webhooks payload reference.

Filtering to what matters

Most CRM use cases only care about some interactions — a completed form, not every open. Add a Filter by Zapier step right after the trigger:

  • Only continue if event.action exactly matches submit (or vote, rate, purchase, etc.) to react to one specific action.
  • Only continue if event.blockId exactly matches a specific block's id (visible in the studio's block inspector) to react to one specific block, ignoring others on the same project.
  • Only continue if lowScore is true to build a manager-alerting Zap for bad CSAT/NPS responses — the same signal MailInApp's own in-app low-score alerts use, routed through your own automation instead.

Pushing contacts back the other way

Automation usually runs both directions: a helpdesk ticket resolves, and you want that person added to (or updated in) a MailInApp contact list for a follow-up send, without a human re-exporting a CSV. Use a Webhooks by Zapier → POST action step as the last step of any Zap — "ticket resolved," "deal closed," "form submitted elsewhere" — pointed at your contact list's row-upsert endpoint to keep a MailInApp send list current automatically.

If a delivery fails

A dead Zap URL, a paused Zap, or a temporary Zapier outage all count as a failed delivery on MailInApp's side. Deliveries are retried automatically with backoff, and any still-failing delivery shows up under Failed deliveries on the Responses page with a manual Redeliver button — see delivery semantics for the full retry schedule. Nothing is ever silently dropped: the interaction itself is always stored in MailInApp first, webhook delivery or not.