Retrieve Order Status

from TB.One to your system

Definition

After you transmitted an order to TB.One it should usually be processed and either be shipped out or cancelled. Partial cancellation is of course also possible. And the customer can still return the order items fully or partially. In that case you get several messages, one for shipping and a few days later the return message.

If you need the changed status information in your system, the TB.One REST API offers an endpoint to get order messages that contain the needed data.

TB.One prepares one message per item of an order. Therefore, if you have an order with several articles, you will receive several messages for that one order. This is necessary since i.e. different articles from one order can be shipped separately and therefore have different tracking codes. Or maybe a customer returns only one of several ordered articles.

Process

  1. Get the list of unprocessed messages from the TB.One REST API. You will receive all open messages with one call.
  2. Write the information (i.e. tracking code or changed order status) for each order or order item to your database.
  3. For each processed message send a “processed” call to TB.One to inform TB.One they do not have to prepare the message again. As long as you do not mark a message as processed, you will get it again and again on each get-messages call.

Preconditions

  • You will need access to TB.One with REST API credentials.
  • You can only receive order messages from TB.One if there are modified orders existing for your channel in TB.One.

Best practices

  1. If you have too many open messages, TB.One can run into a timeout generating the response to your call. Use the limit-Parameter to only get i.e. 100 results at a time.
  2. We recommend to get order messages once or twice a day from TB.One depending on the amount of orders you have. If you work with critical stocks you can make the call up to every 15 minutes.
  3. It makes sense to mark each order as processed directly after its processed in order to do not repeat the same messages if a call aborts in between order message batch.
  4. If an order is cancelled you need to decide if you want to update the stock of your articles accordingly or if you wait for the next article-stock-update from TB.One which should include the re-raised stock.
  5. You should regularily retreive the messages from TB.One. If there are too many unprocessed messages everything gets slower and slower until you will run into a timeout and may not be able to retreive messages anymore at all.

Autor