Callback for reservation change state

We call partner's endpoint for reservation status change not provided by partner via API. Json payload is sent with a reservation identification, new status of the reservation and a changeTime of a change. Changes are sent in the same order as have been created. Changes are being sent several times in case of unsuccessful sending.

Open

As it possible to see on the diagram the change from STOCKED to STOCKED_LOCKED same as change back does not emit the state change callback. The reason is because no state change happens under the hood (the original state is still STOCKED only with additional blocking information).

Technical detail

Partner's endpoint url will be added to partner configuration. POST http method should be used, but we are able to config PATCH http method.

We support several partners' endpoint security options. We are able to just configure these options:

• username and password (basic authorization)

• static bearer token

• static X-Token header

• static Ocp-Apim-Subscription-Key header

We send these information in JSON body:

• reservationId (string) = reservation identification

• status (string) = new reservation status (one of possible states, see API documentation)

• changeTime (datetime in UTC) = reservation change datetime

• flowType (string) = "OUTLET" when customer picks up a package, "INLET" customer brings his own package

• barcodes (array of string) = barcodes of packages

• docNumber (nullable string)

• blocked (boolean) = flag whether parcel is or is not blocked

• errorState (nullable string) = if status is "INCOMPLETE" it can be one of the values: "RESERVED_SLOT_UNAVAILABLE", "RESERVED_SLOT_TOO_SMALL", "RESERVED_SLOT_NOT_FOUND", "BIGGEST_SLOT_NOT_BIG_ENOUGH" or null (not string "null"), otherwise is null (not string "null")

• startReservationDate (nullable datetime in UTC) = new reservation start date in case its time slot has changed (applies for Prereservation and must be enabled by us for you to recieve)

• expirationDate (nullable datetime in UTC) = new reservation expiration date in case its time slot has changed (applies for Prereservation and must be enabled by us for you to recieve)

We can terminate sending process in case of

• a lot of timeouts

• long request processing

Callback payload example

Extended versions of callback payload

You need this type of callback if you implement back flow.

You need this type of callback if you implement prereservation with next reservation times.

Please note the startReservationDate& expirationDate are nullable! It is only filled if the time slot actually changes. Otherwise it is null.