Webhook vs API Request
Three tools, one protocol. The only question that matters is who picks up the phone first — and the answer settles which one you need in about ten seconds.
You now have three ways to move data between Expedify and something else, and they all speak HTTP. People spend a surprising amount of time choosing between them, usually because the differences are described in terms of features rather than in terms of the one thing that actually separates them.
Here is that one thing: who decides when it happens. Everything else follows.
The three shapes
| Mechanism | Who initiates | When it happens |
|---|---|---|
| Webhook Trigger | ||
| Outgoing webhook | ||
| API Request node |
Webhook Trigger
- Who initiates
- When it happens
Outgoing webhook
- Who initiates
- When it happens
API Request node
- Who initiates
- When it happens
The first two are push — something happened, so a call is made. The third is pull — you asked, so an answer came back. Same protocol, opposite direction of intent.
The decision, in order
- Is the other system telling you something? Then it is an incoming webhook, and your only decision is what the workflow does with the payload. There is no alternative — you cannot poll something that has no API, and you should not poll something that offers a webhook.
- Are you telling them, whenever a record changes? Then it is an outgoing webhook. Register their URL, pick the events, done. No workflow to maintain, and the delivery log comes free.
- Are you telling them, but only under conditions the events cannot express? Then it is an API Request node inside a workflow. “When a deal is won and over fifty thousand and the customer is in Europe” is not an event you can subscribe to; it is a workflow with a Condition in it.
- Do you need something back? Then it is an API Request node, always. This is the one that settles most arguments — webhooks are one-way. If you need the other system's answer in order to continue, nothing but a request will do.
The fastest test of all: does the workflow need the response? Webhooks tell. Requests ask. If the next node in your workflow needs to know what the other system said, you are asking, and that is an API Request.
Where people go wrong
Building an outgoing webhook as a workflow, for no reason. If the rule really is “whenever a deal is created, tell this URL”, a subscription does it with no workflow to maintain, no execution history to wade through, and retries and delivery logs you would otherwise have to build. Reach for a workflow when there is a condition or a transformation — not by habit.
Building a workflow as an outgoing webhook, and losing the condition. The opposite mistake. Subscriptions cannot filter — you get every deal, not the ones over a threshold. If you find yourself asking the receiving end to ignore most of what you send, the subscription was the wrong tool.
Polling something that has webhooks. A Scheduler and an API Request every five minutes will work, and it will be slower, more expensive and more code than the webhook that system already offers. Check for a webhooks page before you build a poller.
Expecting a webhook to answer. Both webhook directions are fire-and-forget. The sender learns nothing about what happened downstream, and neither do you. If a decision depends on the other system's reply, that is a request, and no amount of configuration turns a webhook into one.
A worked comparison
Three variations on one requirement, and the different answer each one deserves:
| Requirement | What to build |
|---|---|
- What to build
- What to build
- What to build
Read those three in order and the rule stops being a rule and becomes obvious. The first has no condition and no answer. The second has a condition. The third needs the reply.
Try it
- Take three integrations you actually want and write down, for each, who initiates and whether you need a response. Two columns, no more.
- For any of them where the answer is “they initiate”, go and find their webhooks documentation before you design anything.
- For any where you initiate with no condition and want no reply, build it as a subscription and see how little there is to maintain.
- For the rest, sketch the workflow — trigger, condition, request — and note which node reads the response. That node is your justification for the whole shape.
Next: Testing in the builder — because everything in this module fails silently, and the next four lessons are about finding out why.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read