Eventing
Asynchronous communication from fulfillmenttools towards customer services by leveraging webhooks
Last updated
Asynchronous communication from fulfillmenttools towards customer services by leveraging webhooks
Last updated
Eventing is the way on how fulfillmenttools platform allows external systems to be notified about business events such as "Order has been routed" or "Pickjob has been completed". Please note, that Events are always phrased in past tense, because they describe events that already happened.
Find out how to subscribe to Events and how to process them in this section. Enjoy!
A step wise approach is needed before you can receive your first event from fulfillmenttools. Currently only users with the role Administrator can create new subscriptions.
A subscription needs to be created using the RESTful API. The subscription needs to carry the following information:
A Name (name) for the subscription, which helps identifying the subscription.
Name of the Event (event) you are interested in.
A publicly available endpoint on the internet (callbackUrl). It has to provide access via https protocol.
The headers fulfillmenttools should send along the event request (headers). It is suggested to provide some kind of Authorization Header (e.g. Authorization of X-Authorization) in order to allow your service to check authorized access to your endpoint.
Whenever an event of this kind happens inside of fulfillmenttools a web request is being initiated to all subscriptions.
The endpoint needs to answer with HTTP Code 200: OK within a certain time frame (currently: 10 seconds) in order to signal the successful receiving of the event.
Done.
If the service reachable by the callbackUrl does not answer in time or with a response code other than 200 OK the subscription will initiate an exponential retry pattern of the call (see below). When the event cannot be delivered within a certain time frame (currently 7 days) it is dropped.
Our eventing mechanism does not guarantee correct ordering of events.
We guarantee an at least once delivery of events
While the vast majority of events are being delivered once it could be that from time to time an event reaches the subscription twice. Be aware to cater for this situation by for example also evaluating the entity's version when processing it.
When a configured subscription is not reachable or answers with another response code than 200 OK the fulfillmenttools platform will automatically initiate a retry of the message. The pattern followed is described as exponential backoff which basically means that the time that goes by between the actual retry attemps progressively increases. Please see the following diagram that visualizes the approach:
As you can see above: When a message could not be delivered for the first time there currently is a first retry after 20 seconds.
Retries are being performed after every failed attempt. The time in between the retries will progressively increase with every retry until it reaches 600 seconds (10 minutes). It will stay at that rate until either
the subscription is reachable & acknowledges the message by replying with 200 OK or
message retention is reached (currently: 7 days). It will be dropped then.
Setup a proper monitoring to your configured subscriptions
When operating services, that serve as subscription endpoints it is best practice to also setup a montoring and possibly an alerting as messages will only be retained & retried for 7 days after which the retries will stop and the messages are dropped.
