> For the complete documentation index, see [llms.txt](https://api-docs.urbanpiper.com/downstream/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/webhook-order-retry-api.md).
# Webhook Order Retry API
This endpoint is used by the POS partner to retry the Order Relay webhook for those orders that were missed reaching the POS system. When the POS system requests this API call, our system does check if there are any orders that were returned with a non-2xx status code. For those non-2xx returned status code orders, our system does a webhook retry for the configured endpoint to push those orders again.
{% hint style="warning" %}
**Constraints & Expectations**
A *throttle limit* is applicable on this endpoint limiting the maximum number of requests/hour to **2**. If you breach this threshold, the platform will respond with a `429` error response code.\
\
This API triggers the webhook of the present-day orders. The historical data won't be triggered through this API.
{% endhint %}
Sample cURL
```
curl --request POST \
--url https://pos-int.urbanpiper.com/external/api/v1/webhooks/retry/ \
--header 'Authorization: apikey testusername:testapikey' \
--header 'Content-Type: application/json' \
--data '{
"event_type": 18,
"start_time": 1647834023000,
"end_time": 1647852023000
}'
```
Sample Response
```
{
"status": "success",
"message": "Your request is being processed. You will be receiving the webhook callbacks for the requested timeframe.",
"reference_id": "45faaa55-f28f-46dd-a817-3468444f55fa"
}
```
**Request URL**
**POST** `/external/api/v1/webhooks/retry/`
**Request Headers**
| Parameter | Value |
| :---------------------------------------------: | :----------------------------------------------: |
| `Authorization` | API key-based auth header. Refer authentication. |
**Request Parameters**
| Parameter | Type | Value |
| :------------------------------------------: | :-----: | ------------------------------------------------------------------------------------------------------- |
| `event_type` | integer | You need to put the Order Relay Webhook event ID which is 18 |
| `start_time` | integer | The start time (in epoch milliseconds) from when you want to check for the orders to do a webhook retry |
| `end_time` | integer | The end time (in epoch milliseconds) till when you want to check for the orders to do a webhook retry. |
**Response Parameters**
Requests made to this endpoint are first passed through a basic validation logic and then processed *asynchronously*. The response will either contain any errors that are encountered during validation or, a generic response with a reference UUID is shared.
Once the asynchronous task completes its processing of the request, a webhook callback request is made with the same reference UUID.
| Parameter | Type | Value |
| :---------: | :----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `status` | string | Set to `success` if the payload has been validated and queued. Will be set to `error` if any of the store objects fails in validation. |
| `message` | string | An explanatory message. In case of an error, it will specify the particular store object that failed validation. |
| `reference` | string | A unique ID for the request. This is returned as part of the webhook callback response. Ideally, this should be used to keep track of the status for a particular request made from PoS/ERP system.
NOTE: This will not be returned in case of a validation error.
|
### **Webhook Callback**
External systems can be configured such that when the above request is received on the UrbanPiper platform, a real-time event will trigger a webhook, which in turn will make a POST request to the external system.
The request data will be sent in the body of the request and the format will be JSON. Below is a sample of the JSON data and a detailed explanation of the attributes (explained further below)
**NOTE**: It is expected that the API endpoint to which this webhook makes a request returns a status code in the 2xx series. Otherwise, the platform will mark the delivery as failed and retry later (based on the configured retrial scheme)
Webhook Payload
```
{
"num_webhooks_retry_failed": 2,
"reference_id": "45faaa55-f28f-46dd-a817-3468444f55fa",
"num_webhooks_retried": 8
}
```
`reference` — this is the same unique value that was returned in the response to the request that triggered the bulk store processing flow.
| Parameter | Type | Value |
| :-------------------------: | :-----: | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `num_webhooks_retry_failed` | integer | The number of Orders that were failed to reach the POS system in the webhook retry attempt due to non-2xx status code returned in the response |
| `reference_id` | string | callback reference ID for the request. |
| `num_webhooks_retried` | integer | The end time (in epoch milliseconds) till when you want to check for the orders to do a webhook retry. |
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/webhook-order-retry-api.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.