Every automation that reacts to something happening elsewhere faces the same choice: ask repeatedly (pull), or get notified (push).
# pull — your script asks every 5 minutes "anything new?"
while True:
new_items = check_for_new()
process(new_items)
time.sleep(300)# push — the other side calls your endpoint when something new happens
# (your script is dormant until a POST arrives)
def on_webhook(payload):
process(payload)
When does pull fit, when does push fit?
Pull is great when:
Push is great when:
What's the cost of choosing wrong?
Pull when push fits: you waste rate limits and add latency ("why does this script take 5 minutes to react?"). Push when pull fits: you build receiving infrastructure for an endpoint that fires twice a week.
Every integration between two systems delivers events one of two ways:
| Mode | Mechanism | Latency | Infra you maintain |
|---|---|---|---|
| Pull (poll) | Your script asks the source on a schedule | Polling-interval delay | A scheduler (cron, Vercel Cron) |
| Push (webhook) | The source calls your URL when something happens | Near-zero | A receiving HTTPS endpoint |
Examples: a daily CSV from a file share, an internal database table you query every hour, a public REST endpoint with no push support.
Examples: payment captured → email receipt, GitHub PR opened → ping reviewer, Calendar event accepted → update spreadsheet.
Production systems often do both: webhook for the fast path, periodic poll as a reconciliation check ("did we miss any?"). Push handles 99% of events; pull catches the 1% the webhook delivery missed.
Long polling and streaming protocols are push-shaped even though the connection started from your side. They share push's tradeoff: lower latency, more infra. We treat them as push for this taxonomy.
Most "should I use a webhook?" decisions are answered by step 2. If 5-minute polling latency is acceptable and the source isn't bursty, pull is simpler. If not, build the webhook receiver.
Every automation that reacts to something happening elsewhere faces the same choice: ask repeatedly (pull), or get notified (push).
# pull — your script asks every 5 minutes "anything new?"
while True:
new_items = check_for_new()
process(new_items)
time.sleep(300)# push — the other side calls your endpoint when something new happens
# (your script is dormant until a POST arrives)
def on_webhook(payload):
process(payload)When does pull fit, when does push fit?
Pull is great when:
Push is great when:
What's the cost of choosing wrong?
Pull when push fits: you waste rate limits and add latency ("why does this script take 5 minutes to react?"). Push when pull fits: you build receiving infrastructure for an endpoint that fires twice a week.
Every integration between two systems delivers events one of two ways:
| Mode | Mechanism | Latency | Infra you maintain |
|---|---|---|---|
| Pull (poll) | Your script asks the source on a schedule | Polling-interval delay | A scheduler (cron, Vercel Cron) |
| Push (webhook) | The source calls your URL when something happens | Near-zero | A receiving HTTPS endpoint |
Examples: a daily CSV from a file share, an internal database table you query every hour, a public REST endpoint with no push support.
Examples: payment captured → email receipt, GitHub PR opened → ping reviewer, Calendar event accepted → update spreadsheet.
Production systems often do both: webhook for the fast path, periodic poll as a reconciliation check ("did we miss any?"). Push handles 99% of events; pull catches the 1% the webhook delivery missed.
Long polling and streaming protocols are push-shaped even though the connection started from your side. They share push's tradeoff: lower latency, more infra. We treat them as push for this taxonomy.
Most "should I use a webhook?" decisions are answered by step 2. If 5-minute polling latency is acceptable and the source isn't bursty, pull is simpler. If not, build the webhook receiver.
Create a free account to get started. Paid plans unlock all tracks.