What each one is, plainly
- API: a documented way for one program to ask another for data or to make a change
- Webhook: a message your system sends the moment something happens, so nothing has to poll
- Polling: asking repeatedly “anything new?” — the fallback when there are no webhooks
Webhooks are better than polling: faster, cheaper and less likely to hit rate limits.
Four questions for every vendor
- Do you provide a documented API for reading and writing this data?
- Do you support webhooks, and for which events?
- What are the rate limits?
- Does API access cost extra, or require a higher plan?
Ask in writing before anyone quotes the project. The fourth question in particular has ended more integration plans than any technical constraint.
When there is no API
| Option | Reliability | Cost |
|---|---|---|
| Supported file import | Good | Low |
| Direct database access, if you control it | Good | Medium |
| Vendor-supported integration platform | Good | Medium |
| Browser automation of the interface | Poor | High to maintain |
Browser automation works and it breaks whenever the vendor changes their interface. Use it only as a last resort and budget for the maintenance.
Building it to survive
- Retry with backoff, because transient failures are the normal case
- Idempotency, so a retry cannot create a duplicate
- A durable queue, so nothing is lost during an outage
- Logging of every call and response, with a retention period
- Alerts on repeated failure, routed to someone who can act
Rate limits are a design constraint
A limit of a few hundred calls a minute shapes how you batch work and how quickly you can backfill history. Find the number before designing, not during testing.
It is also why the initial data load is often the hardest part of an integration to schedule.