Webhooks error handling and limitations

Destination webhooks allow you to send data from Stedi to third-party services without writing any custom code.

​

Limitations

Destinations has certain limitations. If your system’s API has different requirements, you can set the destination target to be:

• A function, such as AWS Lambda, Google Cloud Functions, or Azure Functions, which can then call the third-party API
• An iPaaS platform, such as Zapier or Workato, which can then call the third-party API.

​

HTTP response codes

Stedi considers a 2xx response a success, and marks any other response as a failure.

Stedi retries events associated with status codes other than 2xx for up to 5 hours.

In the event of an error response (after the retry period), Stedi adds the event to the error queue for the destination.

To prevent throttling, you can set a Max executions per second when configuring the destination.

​

Response time

The target endpoint must respond within 5 seconds, or the event will be counted as a failed delivery.

​

Retries

When a destination delivery fails, Stedi will retry up to 5 times every 90 seconds. After the fifth retry, Stedi moves the event to the error queue.

​

Error queue

Each destination includes an error queue. Each item in the queue consists of the original event that was attempted to be delivered. This ensures if the target service has some downtime, or anything else goes wrong, the missed events can be retried later. The error queue retains items for 14 days.

Viewing the HTTP response from the third-party service is not currently supported.

The order of the error queue is not guaranteed. The downstream service must be designed to be idempotent to handle at-least-once delivery of events, and must accept events out of order.

​

Logs

To make debugging easier, you can set the log level for each Destination webhook. You can edit the webhook to switch between the following log levels at any time:

• OFF - no logs
• ERROR - errors only
• INFO - errors and select execution steps, such as successful deliveries
• TRACE - all execution steps

To view logs, click the Destination to go to its detail page, and then navigate to the Logs tab.

​

Deauthorized connections

If a destination sends a message to an endpoint that returns a 401 (Unauthorized) response, or the OAuth endpoint returns an error, the destination will be ‘deauthorized’. In this state, the destination won’t be able to deliver messages.

If there is an issue with your authentication information (such as the password, API key, or OAuth settings), edit the destination to fix it.

If the authentication information is correct, and there was a different reason for the endpoint returning a 401, you can try again by adding a temporary header. Edit the destination, and under the advanced toggle, add any header and value. For example, x-stedi-reauthorize with today’s date as a value. When you save, the destination will attempt to deliver again. This header can be removed later. Editing the value of a header will also restart deliveries.

You will likely have a queue of messages to deliver, so after making this change they will start automatically being retried. If the endpoint is still returning an invalid response, the destination will return to Deauthorized