Event Driven
Notes
- This section contains documentation for HTTP communication channels which were previously known as "Integrations" and was located under settings
- Communication channels are also known as destinations.
Overview
To receive data from Orderful to an external system, you must configure an inbound communication channel, then assign it to an inbound relationship.
How To Create an HTTP inbound communication channel
- Go to the Communication Channles menu from the left panel.
- Click on "Create Channel" and select HTTP from the drop-down menu.
- From the "Create New HTTP Channel" pop-up, enter a name, the URL that you would like Orderful use to send transactions to, and its data format. You can also choose an authorization type such as OAuth.
Note
We currently only support OAuth2.0 JWT.
- Click "Create" to complete the setup.
How to set an inbound communication channel as default
After creating your communication channel, you can set it as default.
The default inbound communication channel is assigned to any new inbound relationships. by default. You can of course override the default communication channel at a relationship level, if needed.
To set a communication channel as default, click the "Default Inbound Channel" dropdown and select the desired channel.
How to assign a specific inbound communication channel to an inbound relationship
To assign to a relationship,:
- Go to the "Relationships" page.
- Click on an inbound relationship row.
- Assign a communication channel from the right side panel.
Channel Behaviour
After a communication channel has been assigned to a relationship (by default or manually), new transactions that belong to this relationship are sent to the assigned communication channel.
POST body of transaction in the request can be found here
Timeouts and Retries
When we send a webhook request, we will wait for 30s before retrying the same request if we have not received a response from you.
We will retry up to three times before we give up.
Transaction Statuses and Handling HTTP Status Codes
When we send you a transaction to the assigned communication channel, we adjust the status of the transaction based on the HTTP response code we receive from you. See below for the expected behavior:
HTTP Response Received | Behavior | Transaction Status |
---|---|---|
200 | Request was successful. | ACCEPTED |
202 | Request was successful but not yet acted upon. | DISPATCHED** |
400 | We will reject the transaction immediately and not retry. | REJECTED |
400-series except 400 and 429 | We will fail the transaction immediately and not retry. | FAILED |
500-series or 429 | We will retry sending the transaction up to 3 times before updating the transaction status. | FAILED |
** If you send a 202 response code, you'll have to manually update the status to ACCEPTED using /accept endpoint.
You can read more about transaction statuses here.
Clean-Up Processes
If you go with a push integration model approach, you may want to run an asynchronous clean-up process to catch any transactions that may have failed to deliver outside of our retry boundaries. A call to achieve this might look like this: https\://api.orderful.com/v2/transactions?status=FAILED
Updated about 2 years ago