Make integration
Make is on the map, not in the product yet.
Pipeline events fired at your Make scenarios, so anything downstream can react to published, indexed, or won.
How it works
Make connects through a scenario's custom webhook. In Make, you add a custom webhook trigger to a scenario and paste its URL into SearchHandled, and from then on the events you select, article published, page indexed, ranking milestone reached, fire at that scenario the moment they happen. Make's side of the wiring then routes the event into any of the apps its platform connects.
In the loop, Make is an extension cord like Zapier, for teams who prefer Make's visual scenario builder or its pricing. A published article can append to a database, an indexing confirmation can update a client tracker, a ranking milestone can trigger a celebration post. The logic lives in your scenarios where your team can see and edit it; we supply a clean, prompt event stream with stable field names.
Best forTeams automating in Make who want pipeline events triggering their scenarios without custom code.
Setup, step by step
- In Make, create or open a scenario and add the custom webhook trigger module.
- Copy the webhook URL Make generates.
- Paste it into SearchHandled's Make connector and choose which events to send.
- Send the test event and let Make's webhook determine the data structure from it.
- Build out the rest of the scenario against the mapped fields and turn it on.
Best practices
Determine the structure from a real event
Make learns a webhook's data shape from what it receives. Send the test event before building the scenario so every field you map is one Make has actually seen.
One scenario per job
Each Make webhook belongs to one scenario, so give each job its own: one scenario logging published articles, another alerting on milestones. Small scenarios keep run histories readable and failures isolated.
Filter inside the scenario
You choose event types in our connector, and Make's filters refine further, such as acting only on milestones for a specific site. Coarse selection on our side, fine filtering on yours.
Watch the scenario history after changes
Make's run history shows each incoming event and what the scenario did with it. After editing a scenario, glance at the next few runs to confirm mappings still line up.
Known issues
What practitioners actually report, from official docs, issue trackers, and community forums.
Rate limits per webhook
Make accepts up to 30 requests per second per webhook, so a burst of events beyond that would be rejected at the edge.
How we handle itOur dispatcher queues outbound events per webhook and stays inside the limit, so bursts from the pipeline are smoothed into a rate Make always accepts, with no events dropped.
developers.make.com
One webhook serves one scenario
A Make custom webhook is bound to a single scenario, so one URL cannot fan events into several scenarios directly.
How we handle itConnect multiple webhooks in SearchHandled, one per scenario, each with its own event selection. Alternatively, one receiving scenario can route to others using Make's own tools.
developers.make.com
Questions teams ask
- Which events can we send to Make?
Article published, page indexed, and ranking milestone reached, selected per connection. Each event carries stable field names, so scenario mappings do not break as we ship updates.
- Can Make trigger actions inside SearchHandled?
This connection is outbound: our events trigger your scenarios. For inbound automation, the Zapier integration includes a request-article action, and our API covers custom cases.
- Does this cost anything extra?
Nothing from us. Make's own plan governs how many operations your scenarios consume, and each event we send that a scenario processes uses operations on Make's side as usual.
Not connectable yet
Start with the plan, not the connector.
Build a Growth Map from your site to see the work itself. Approved pages can leave through the export or the webhook today, and telling us Make matters moves it up the rollout.