Eventing

Asynchronous communication from fulfillmenttools towards customer services by leveraging webhooks

This page is outdated. Please go to our new documentation under https://docs.fulfillmenttools.com/documentation.

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.

Drawing

Find out how to subscribe to Events and how to process them in this section. Enjoy!

Preparations

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.

  1. A subscription needs to be created using the RESTful API. The subscription needs to carry the following information:

    1. A Name (name) for the subscription, which helps identifying the subscription.

    2. Name of the Event (event) you are interested in.

    3. A publicly available endpoint on the internet (callbackUrl). It has to provide access via https protocol.

    4. 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.

  2. Whenever an event of this kind happens inside of fulfillmenttools a web request is being initiated to all subscriptions.

  3. 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.

  4. Done.

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.

Retrying failed messages

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:

Drawing
Exponential Backoff when retrying messages

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.

Last updated

Was this helpful?