CampaignStack with Make: a scenario in, a webhook out

Make's canvas is where a lot of agencies already route data between tools, and its built-in sha256 function makes it the easiest of the automation platforms to sign a request with. A scenario posts leads into a CampaignStack workflow over a signed webhook; a webhook step in CampaignStack fires a Make webhook on whichever exit you care about. Two modules on the Make side, two clicks on ours.

Jump to the setup See CampaignStack pricing

What Make owns

The routing between everything else: iterators over sheets and CRMs, routers with filters, error handlers, scheduling, and the cheapest operations pricing in its category. If the lead is born or transformed in a Make scenario today, keep the scenario. Add one HTTP module at the end of it.

What CampaignStack owns

The outreach. Make's LinkedIn app publishes posts and nothing else, and an HTTP module cannot hold a LinkedIn session, respect a per-account budget or notice a reply. CampaignStack does those, plus the AI drafts, the critic, the review queue and the router that cancels queued touches when a reply lands. The scenario hands the lead over; the exit webhook hands the outcome back.

Side by side

Where each module attaches

Two connections, what fires them, and what arrives on the other side.

	On the Make side	On the CampaignStack side
Leads in	Any trigger, a JSON module or a text aggregator building the body, an HTTP module posting it with the sha256 formula in a header.	A workflow's Webhook source. Leads land workspace-scoped, get enriched and scored, and enter the graph.
Outcomes out	A Custom webhook trigger, then whatever the scenario should do with the lead and its exit.	A Webhook step on the exit that matters: replied, meeting booked, not interested, finished. It posts the body you template.

Setup

Set it up

Inbound first, then the outcomes scenario. Both are independent.

Create the webhook source in CampaignStack

Open the workflow, click its source node, add a provider and choose Webhook. You get the endpoint URL, a signing secret and a curl example, each with a Copy button. The token in the URL identifies the source; the secret signs the body.

PAYLOAD='{"leads":[{"linkedinUrl":"https://linkedin.com/in/janedoe","fullName":"Jane Doe"}]}'
SIG=$(printf '%s' "$PAYLOAD" | openssl dgst -sha256 -hmac "<your-secret>" | cut -d" " -f2)

curl -X POST 'https://actions.campaignstack.io/api/webhooks/workflow-leads/<your-token>' \
  -H 'Content-Type: application/json' \
  -H "X-Webhook-Signature: $SIG" \
  -d "$PAYLOAD"

Build the body and sign it in the HTTP module

Use a Create JSON module (or a Text aggregator) to produce the payload as one string, and reference its output as a variable. In the HTTP module, Make a request: method POST, URL from step 1, body type Raw, content type JSON, the payload variable as the body, and a header whose value is the sha256 formula below with the secret and hex encoding. The string you sign must be exactly the string you send, so sign the same variable you pass as the body.

{
  "leads": [
    {
      "linkedinUrl": "https://linkedin.com/in/janedoe",
      "fullName": "Jane Doe",
      "email": "jane@acme.com",
      "title": "VP Sales",
      "companyName": "Acme"
    }
  ]
}

# header
X-Webhook-Signature: {{sha256(1.payload; "hex"; "<your-secret>")}}

Hear back with a custom webhook

New scenario, first module Webhooks, Custom webhook; copy its URL. In CampaignStack, add a Webhook step on the exit you want to react to, paste the URL, pick POST and template the body with lead fields. Run the step once so Make can determine the data structure, then wire the rest of the scenario.

{
  "name": "{{lead:fullName}}",
  "title": "{{lead:title}}",
  "company": "{{lead:company}}",
  "linkedin": "{{lead:linkedinUrl}}",
  "email": "{{lead:email}}"
}

01 · Why the boundary is here

The canvas routes, the outreach system remembers

Make is excellent at moving a record from one place to another and terrible, by design, at remembering what happened to that record last week. Outreach is mostly memory: what this account already sent today, whether this person replied, whether someone on the team already booked them. CampaignStack keeps that memory and exposes the two moments Make needs, the hand-over and the outcome, as webhooks. Everything between them stays out of the scenario, which is what keeps the scenario simple.

02 · Provenance

Webhook leads are yours, not the shared database's

Leads that arrive over a webhook are user-supplied, so they land workspace-scoped: they never enter the shared lead database other workspaces read from and never cross a workspace boundary. They are enriched, scored and worked like any other lead, and your exclusions are checked at every send.

Frequently asked questions

Does Make's sha256 function do HMAC?

Yes. With a third argument the function computes HMAC-SHA256 with that key; with the second argument set to hex it returns the encoding the endpoint expects. No custom code module is needed.

How many leads can one request carry?

Up to 100 leads per request and 1,000 per hour per source. Use an aggregator to batch an iterator's rows rather than one HTTP call per row.

What arrives at the custom webhook?

Whatever you templated in the CampaignStack Webhook step: lead fields, the exit it took, and any constant you add. Make determines the structure from the first call, so send one test before mapping.