🪝Web Hooks

Introduction

Webhooks are a way for applications to communicate with each other in real-time. By using Webhooks, Inqud can send automated messages or data updates to other systems whenever certain events occur. Unlike traditional APIs, which require regular polling for updates, Webhooks push information instantly, ensuring timely and efficient data transfer. The type of webhook you need will vary based on how you integrate Inqud into your business and which Inqud product you are using.

Web Hook Source IP

Inqud sends POST payloads with raw JSON to your webhook URL from the following IP address:

3.64.51.60

Web Hook Retries

If your webhook endpoint returns a non-200 response or no response within 10 seconds, Inqud will retry sending the webhook up to 10 times. There will be a few minutes between each retry, with the delay between attempts increasing exponentially.

Web Hook Verification

If a webhook secret is set up, a special header will be passed along with every webhook request:

X-Payload-Digest

The value of this header is an HMAC-SHA1 signature of the callback's body, created using the callback secret provided by the user.

Visit the page below for example:

Web Hook Verification

Best practices

To ensure reliable processing, design your application to handle duplicate and out-of-order webhooks. Implement idempotency for actions taken upon receiving a webhook, ensuring that repeated requests do not cause unintended effects. If your application relies on webhooks to drive state changes, ensure that your code does not depend on the specific order in which webhooks are received.

In case of extended downtime beyond Inqud's retry period, webhooks may be lost. If your application uses webhooks for state transitions, implement self-healing mechanisms by querying Inqud's other endpoints to verify item states when a webhook is not received within an expected timeframe. All data provided in webhooks is also accessible through our other APIs.

For optimal performance, keep your webhook receiver as simple as possible. A recommended approach is to have the receiver write the webhook data into a queue or reliable storage. This ensures two key benefits:

1. Quick response times within the 10-second window to avoid failed deliveries.

2. Stability during unpredictable rates of webhook arrivals, preventing potential overloads or rate-limiting issues, especially if your receiver performs intensive tasks like generating and sending emails.