REST API vs. Webhook: Differences, Examples and Archi…

Understand REST API polling versus webhook callbacks, with JSON examples, event authentication, queues, idempotency and Business Central integration patterns.

1. Start with the core concepts

A REST API exposes resources and operations through HTTP. The client chooses when to request data. A webhook is an event-triggered HTTP callback sent to a subscribed destination. REST is an architectural style; webhook is a delivery pattern. A system can use both.

2. Pull versus push

With polling, a client repeatedly calls an endpoint such as GET /api/orders/42. With a webhook, the source sends a POST to a registered callback whenever a relevant event occurs. Webhooks can reduce delay but require reliable and secure delivery handling.

3. REST request example

A shop requests orders using GET and receives JSON. This pattern works well when clients need to retrieve information on demand.

GET /api/orders/10042 HTTP/1.1
Accept: application/json

4. Webhook payload example

After an order status update, the source sends a JSON event to an Azure Function. The receiver should acknowledge only after the event has been accepted appropriately, typically with durable storage if downstream processing is asynchronous.

POST /webhooks/orders HTTP/1.1
Content-Type: application/json
X-Event-Id: evt-10042

{
  "eventId": "evt-10042",
  "type": "order.updated",
  "orderId": "10042",
  "status": "Shipped"
}

5. Authenticate incoming webhooks

Public callbacks require authentication. Depending on the provider, use HMAC signatures, a shared secret, OAuth or a different documented scheme. Verify signatures over the original raw request bytes and validate timestamps when supported. An unguessable URL is not sufficient access control.

6. Duplicates and out-of-order messages

Events may arrive more than once or out of sequence. Persist unique event IDs and deduplicate processing. Use version fields or timestamps where available to reject stale updates. Do not assume exactly-once delivery.

7. Why queues matter

A webhook gateway validates and authenticates an incoming event, persists it in a durable queue and returns a prompt acknowledgment. A worker processes it separately with controlled retries and clear failure states. This improves resilience during downstream outages.

8. REST APIs and Business Central

Business Central can call external REST services using AL HttpClient. An Azure Function or another protected service can receive webhooks and then interact with Business Central over approved APIs. Check supported native event and webhook functionality in the targeted BC release.

9. Test failure modes

Deliver the same event twice, simulate interruption after queue persistence and submit invalid signatures. Verify error responses, payload validation and provider-specific retry behavior.

10. Which should you choose?

Use REST requests when clients need to fetch data on demand. Use webhooks for timely event notifications. A common architecture combines both: an event webhook announces a change and the receiver fetches the current record through a REST API.

REST API vs. Webhook: Differences, Examples and Architecture