The difference in one table
An API call is a question you ask when you want an answer now: send this, fetch that. A webhook is a standing instruction: when this happens, tell me at this URL. The API puts you in control of timing; the webhook puts the event in control.
Polling an API for changes is the tell you needed a webhook: asking "anything new?" every minute is expensive on both sides and still up to a minute late. The push arrives once, when it happened.
In email, you need both
Email makes the split concrete. The API sends the message: POST, message ID back, done. The webhook reports its life afterwards: delivered, opened, clicked, bounced, complained, each POSTed to your endpoint as it happens.
Build with only the API and you're blind after the send. Build with only webhooks and you can't send. The two are one loop: act through the API, react through the webhook, and let your agent close the loop, a bounce fires, the contact gets suppressed, and you read about it afterwards.
A real trace of that loop from our own ops: a send reports six failures, and every one reads "contact email is suppressed" from earlier bounce suppressions. That's the system working: yesterday's webhook events protecting today's API calls, with nobody watching a dashboard in between.
Agents bend the pull-push split in an interesting way. An agent is transient: it runs, acts, and exits, so it usually can't host the public HTTPS endpoint a webhook wants to POST to. Agents poll. The first fully productized MCP client on our platform checks campaign state every fifteen minutes, and across all our agent traffic, 43 percent of tool calls are telemetry queries: agents asking what happened, then deciding what to do next. Push for servers, pull for agents, the same events underneath both.
Full parameters and responses live in the REST API docs and the API reference.
Go deeper
The mechanics: webhooks explained. Before production: test your webhook and secure it.