Skip to content

REST API and webhook: what is the difference?

Both connect systems, but the direction is reversed — and almost everything else follows from that: timeliness, effort and the question of what happens in the event of a failure.

  • Who it is forProject leads, IT managers
  • LevelIntermediate
  • Reading timeabout 7 minutes
  • Last updated16 October 2026

What you will learn

  • What defines a REST interface
  • What a webhook is and who calls whom
  • What costs each pattern brings with it
  • Why both are often built together

REST: your system asks

With a REST interface, your system makes the request and gets a response. The address names the thing, the method the intent.

HTTPExample request
GET /api/v1/auftraege?seit=2026-10-16 HTTP/1.1 Host: beispiel.de Authorization: Bearer <Zugangsschluessel> Accept: application/json # Antwort HTTP/1.1 200 OK Content-Type: application/json {"auftraege": [{"nummer": 10244, "status": "offen"}]}
GET retrieves, POST creates, PATCH changes, DELETE removes. The status code says whether it worked — 2xx means success (200 with content, 201 created, 204 no content), 4xx an error on the part of the requester, 5xx one on the part of the target system.

The practical advantage: your system decides the timing. If it was unreachable for an hour, it simply asks again afterwards. This requires the interface to still supply the missed period, for example via a time filter with sufficient retention; changes that affect only the current state cannot then be reconstructed.

Webhook: the other system calls

With a webhook, you register an address with the other system. When something happens there, it sends a request to that address — without you having asked.

The advantage is timeliness: the event reaches you in seconds instead of at the next poll. The price is three things that do not exist with polling: your address must be reachable from outside, you must be able to verify that the message is genuine, and you need a plan for lost messages.

The last point is the one most often overlooked. If your system was unreachable for twenty minutes, it depends on the other system whether it retries the message — and whether it does so often enough.

An example from practice

Why both are built together

The usual solution is not either-or, but both: webhooks for the normal case, plus a regular poll as a safety net underneath that catches up on whatever did not arrive. This looks redundant and is the answer to the question of what happens in the event of a failure.

For this to work, processing must be repeatable: the same message processed twice must not create a second record. For that, each message carries a unique identifier that the receiving system remembers.

Which pattern fits?

  • Data may be up to a day old → polling, possibly even as a nightly file comparison.
  • Data must arrive within minutes → webhook plus polling as a safety net.
  • The other system offers only one of the two → the decision has already been made.
  • Your system is not reachable from outside → polling, because a webhook cannot reach you.

Common misconceptions

It is more up to date and more laborious. For many business processes, polling is the more robust choice.

JSON is common, but not the definition. What matters is addressing via resources, the meaning of the methods and the status codes.

It means that the request was accepted. Whether the record was also created correctly in business terms in the target system is only revealed by the response to it.

Further sources

Further reading

What is an API?The fundamentals that come before.
API integrationOur service on the topic.
Connecting Excel, email and specialist softwareWhen there is no interface.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design and writes here about decisions that arise in real projects.

Questions about the article? Write to us