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.

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")

We can terminate sending process in case of

• a lot of timeouts

• long request processing

Callback payload example

{
    "reservationId": "91fcb674-bfbc-4f88-9bef-9651874e8126",
    "status": "PICKED_UP",
    "changeTime": "2021-10-20T08:31:58.113Z"
}

Extended version of callback payload

You need this type of callback if you implement back flow

{
  "reservationId": "hMg8VDP8oldBNVgAOBvH",
  "status": "RETURNING",
  "changeTime": "2022-12-30T13:00:32.42Z",
  "flowType": "INLET",
  "barcodes": ["7032102989999912"],
  "docNumber": "hMg8VDP8oldBNVgAOBvH",
  "blocked": false,
  "errorState": null
}