# Webhooks, the API or event triggers? Drum gives another system three ways to keep up with what happens in an account: webhook events, the REST API, and event triggers that send a webhook. They answer different questions, and the best integrations usually combine them. ## Webhooks answer "what just changed?" A webhook arrives within seconds of a change, without your system asking. It suits work that should happen as soon as something changes in Drum: posting a won opportunity to a team channel, creating a job in a field system when a project starts, copying an approved invoice to a reporting database. Webhooks cover a deliberate, small set of records (projects and opportunities, invoices, costs and company merges) because those are the changes most integrations need to act on. Each event carries the record's main fields, but not everything Drum knows about it. ## The API answers "what is true now?" The [REST API](/api/) reads any record the token's user can see, with all its detail, whenever you ask. It suits a first full copy of the data, a nightly reconciliation, and anything the webhook payload does not include. Polling the API on a timer to spot changes works, but it is slow to notice and does work even when nothing changed. Webhooks are the better trigger. The API is the better source of detail. ## Together A common pattern: 1. Load the current records once through the API. 2. Subscribe to the events for those records. 3. When an event arrives, use its payload, or read the record through the API if you need more. 4. Reconcile through the API now and then, to catch anything a failed delivery missed. This gives you changes as they happen, full detail when you need it, and a safety net for the deliveries no system can guarantee. ## Event triggers answer "did this specific thing happen?" An [event trigger](/webhooks/how-to/send-a-webhook-from-an-event-trigger/) is set up in Drum by an admin, not by your code. It watches for one business event, such as a timesheet approved or a task completed, can be narrowed by client, team or project status, and sends `trigger.fired` when it matches. Use a trigger when: - The record has no webhook event of its own: tasks, timesheets, expense claims, progress claims, quotes, purchase orders and project role assignments. - The integration cares about one moment, not every change. "Quote accepted" is simpler to handle than every `.updated` event and a check for the status. - The people running Drum should be able to switch it on, off or change its filters without a code change. The trade-off is that a trigger lives in the account's settings. Someone can turn it off, and your integration cannot create it through the API. If your integration depends on a trigger, say so in its setup instructions. ## The MCP server is for people, not systems The [MCP server](/mcp/) lets an AI assistant act in Drum for one person. It does not push events. An agent that should react to changes in Drum still needs a webhook to wake it up, and then can use the MCP server or the API to act.

Drum gives another system three ways to keep up with what happens in an account: webhook events, the REST API, and event triggers that send a webhook. They answer different questions, and the best integrations usually combine them.

Webhooks answer “what just changed?”

A webhook arrives within seconds of a change, without your system asking. It suits work that should happen as soon as something changes in Drum: posting a won opportunity to a team channel, creating a job in a field system when a project starts, copying an approved invoice to a reporting database.

Webhooks cover a deliberate, small set of records (projects and opportunities, invoices, costs and company merges) because those are the changes most integrations need to act on. Each event carries the record’s main fields, but not everything Drum knows about it.

The API answers “what is true now?”

The REST API reads any record the token’s user can see, with all its detail, whenever you ask. It suits a first full copy of the data, a nightly reconciliation, and anything the webhook payload does not include.

Polling the API on a timer to spot changes works, but it is slow to notice and does work even when nothing changed. Webhooks are the better trigger. The API is the better source of detail.

Together

A common pattern:

1. Load the current records once through the API.
2. Subscribe to the events for those records.
3. When an event arrives, use its payload, or read the record through the API if you need more.
4. Reconcile through the API now and then, to catch anything a failed delivery missed.

This gives you changes as they happen, full detail when you need it, and a safety net for the deliveries no system can guarantee.

Event triggers answer “did this specific thing happen?”

An event trigger is set up in Drum by an admin, not by your code. It watches for one business event, such as a timesheet approved or a task completed, can be narrowed by client, team or project status, and sends trigger.fired when it matches.

Use a trigger when:

• The record has no webhook event of its own: tasks, timesheets, expense claims, progress claims, quotes, purchase orders and project role assignments.
• The integration cares about one moment, not every change. “Quote accepted” is simpler to handle than every .updated event and a check for the status.
• The people running Drum should be able to switch it on, off or change its filters without a code change.

The trade-off is that a trigger lives in the account’s settings. Someone can turn it off, and your integration cannot create it through the API. If your integration depends on a trigger, say so in its setup instructions.

The MCP server is for people, not systems

The MCP server lets an AI assistant act in Drum for one person. It does not push events. An agent that should react to changes in Drum still needs a webhook to wake it up, and then can use the MCP server or the API to act.