Make + SalesCrew
No listed Make module. A custom webhook module catches events from SalesCrew, and an HTTP module writes back through the API or an MCP tool.
- Custom webhook, not a module
- Signed and retried out
- Scoped token in
The short answer
- SalesCrew has no app in the Make catalogue. The connection is Make's own Custom Webhook module on the trigger side and its HTTP module on the action side.
- Everything an event can carry is available this way, because the events map to the same actions the app and the MCP server expose. What you lose is a browsable module, not capability.
- Deliveries out are signed and retried and every failure is visible; writes in use a token scoped by channel, profile and area, and land in the audit log with that token named as the actor.
Mechanism
The first row is the one people assume wrongly.
| What | Mechanism | Direction | Objects | Status |
|---|---|---|---|---|
| Make module in the catalogue | Does not exist | , | , | Not available |
| SalesCrew to Make | Outbound webhook to a Make Custom Webhook URL | Outbound | Any registered event | Available |
| Delivery reliability | Deliveries logged, retries automatic, secret rotatable | Outbound | Webhook deliveries | Available |
| Make to SalesCrew | Make HTTP module posting to the SalesCrew API | Inbound | Contacts, companies, deals, tasks, leads | Available |
| Make to SalesCrew over MCP | HTTP module calling an MCP tool with a scoped token | Inbound | Every action the UI has | Available |
| Instant triggers in the scenario builder | Only through the Custom Webhook module | , | , | By design |
Mechanisms read from the SalesCrew integration table, September 2026. Make's own pricing decides what a webhook-driven scenario costs in operations.
Setup
Ten minutes for the first scenario.
- 1
Add a Custom Webhook module
In a new Make scenario, add Webhooks then Custom Webhook, create it and copy the address.
- 2
Register it in SalesCrew
webhook_create with that URL and the events you want. webhook_test sends a sample so Make can learn the payload shape.
- 3
Let Make determine the structure
Run the test while Make is listening, and the scenario builder maps the JSON for you.
- 4
Build the write direction
An HTTP module posting to the API, or calling an MCP tool with a token from mcp_token_issue scoped as tightly as the job allows.
- 5
Handle errors deliberately
Give the scenario an error route. On the SalesCrew side, webhook_deliveries shows failures and webhook_retry replays one.
- 6
Rotate the secret on staff changes
webhook_rotate_secret changes the signing key without rebuilding the scenario.
Why the wording matters
Questions
- Is a Make module planned?
- It is not on the published roadmap. Outbound webhooks, the API and the MCP server are the supported path.
- Can Make read data out of SalesCrew on a schedule?
- Yes, with an HTTP module against the API or an MCP read tool. Webhooks handle events; polling handles snapshots.
- How many webhooks can I register?
- Register one per destination or one per event group, whichever keeps your scenarios readable. Deliveries and retries are recorded either way.
- What happens if Make is down?
- Deliveries fail and retry, and the failed ones stay visible so you can replay them rather than discovering a silent gap weeks later.
- Is MCP a better route than the API here?
- For anything an agent might also do, yes, because the tool carries the same permission model as a person and the same approval behaviour on external sends.
Build the scenario without waiting for a module
A custom webhook and an HTTP call cover the work a catalogue entry would do.