No-code deliverability monitoring with Make.com

If your team runs on Make.com (formerly Integromat), you already know how much glue code it replaces. The same approach works for continuous deliverability monitoring. This scenario fires an Inbox Check placement test every time a campaign is queued in your ESP, waits for the verdict, and writes the result to an Airtable base your team already watches.

Prerequisites

• A Make.com account (free tier is enough for a few hundred scenario runs).
• An Inbox Check API key.
• An Airtable base with a table called Deliverability Runs.
• (Optional) A Slack incoming webhook.
• A trigger — any ESP webhook or a simple schedule.

Step 1 — Prep the Airtable base

Columns we use:

• Run ID (auto number)
• Campaign (single-line text)
• Started (date)
• Inbox rate (number, 0–100)
• Gmail, Outlook, Yahoo, Mail.ru (single-select: inbox / promotions / spam / missing)
• Share URL (URL)

Step 2 — Build the scenario

1. Trigger: Webhooks → Custom webhook. Generate the URL and paste it into your ESP's webhook settings for the campaign-queued event.
2. HTTP → Make a request. Create the placement test. Method POST, URL https://check.live-direct-marketing.online/api/tests. Headers: Authorization: Bearer {{apiKey}}, Content-Type: application/json. Body:

{
  "sender": "{{1.campaign.fromAddress}}",
  "subject": "{{1.campaign.subject}}",
  "html": "{{1.campaign.html}}",
  "providers": ["gmail", "outlook", "yahoo", "mailru", "yandex"]
}

1. Sleep module — wait 60 seconds. Most placement tests complete in under 2 minutes; we poll twice if needed.
2. HTTP → Make a request. Poll the test. Method GET, URL https://check.live-direct-marketing.online/api/tests/{{2.data.testId}}.
3. Router → split on {{status}}. If done, continue. If not, loop back to sleep.
4. Iterator over providers. Lets us reshape the array for Airtable.
5. Array aggregator — group iterator output into a single object keyed by provider name, so we can write one Airtable row.
6. Tools → Set variable — compute inboxRate =count(folder=inbox) / total * 100.
7. Airtable → Create a record — map fields into the table from step 1.
8. Router → Slack conditional. If inboxRate < 80, send a message via the Slack webhook; otherwise end.

Step 3 — Secrets and connections

Make.com supports per-module Connections. Create one for Airtable with a personal access token, one for Slack using the webhook URL as a custom connection, and keep the Inbox Check API key in a scenario-level Global variable named apiKey. Referenced in the HTTP modules as {{apiKey}}.

Step 4 — Trigger modes

A. ESP webhook trigger

The strongest pattern. When Mailchimp/SendGrid/Klaviyo fires campaign.queuedor a send-window event, the scenario runs. The downside: ESPs vary wildly in what they expose as webhooks.

B. Scheduled (no ESP webhook)

If your ESP does not expose a useful webhook, run the scenario on a fixed schedule — every 30 minutes, using a static sender + template. Less tied to real traffic, but enough to catch reputation drops.

C. Airtable-driven

Add a "Run now" checkbox column in Airtable and trigger the scenario on row update. Marketers toggle the checkbox, Make runs a test, row gets populated. Great for teams who live in Airtable anyway.

A note on Make.com operations

Every module run in Make counts as one or more "operations". The above scenario runs ~10 operations per test. Free tier is 1,000 ops/month (≈100 tests). Heavy users should upgrade or collapse modules — for example, aggregating in a single HTTP call to your own backend.

Why Make, not n8n or Zapier?

• Zapier is the fastest to learn but limits iterators and multi-step logic on low tiers.
• n8n is the most powerful but you self-host it.
• Make is the compromise: visual scenario builder, cheap, and its Router + Iterator + Aggregator combo is the best-in-class for API chains like this one.

FAQ