Articles by Category

Setting up your API integration

Updated on 10 May 2024

Our API can be used in a number of ways to integrate with other systems.

In the majority of cases, a one-way integration is sufficient, to automatically create orders for delivery/collection, however an integration can be taken further with a more conversational approach, providing status updates in both directions.

An integration would need to be developed between the two systems to achieve this if one does not already exist for the platforms you are using.

Your developers can build custom integrations using our Public API.

Typical Data Flow

Using our API, you can automate the creation of orders for delivery/collection.

This is generally based on a trigger point in your existing systems, which would be defined as part of the integration development (such as an order status change).

A typical data flow between the two systems would be as follows.

  • The third-party system would send orders (or jobs) into Stream to be processed and delivered/collected.
  • When they are completed, the status in Stream can be reflected back in the third-party system, as illustrated in the graphic below:

Integrations can be more comprehensive beyond creating orders or getting delivery status updates only and are dependent on the customer’s specific operational processes.

If required, once orders are planned onto routes this information can be fed back for use in a WMS system for picking to the appropriate vehicles/routes.

Further API services are available and can be discussed with the our support team to agree on the best approach.

API Documentation

You can view our API Documentation using the link below.

View API Documentation >

The minimum order information, required to be provided via the API, is listed below:

  • OrderNo = Order Number – unique for every order (likely using the dispatch reference number)
  • Order Date – (e.g. booking date or date an order was placed)
  • Order Type – (i.e. Delivery or Pickup/Collection or Multi-Order)
  • Customer Name (Individual B2C or business name B2B)
  • Contact Details – Optional, but recommended. Particularly the mobile number and/or email address, which can be used to send customer notifications.
  • Collection / Delivery Address information consisting of:
    • Address (Lines 1-3)
    • Town 
    • County
    • Postal Code
    • Country
    • As an alternative/extension to the above, Lat/Long coordinates can be used.Note: As addresses are validated by Google Maps in Stream, these can often contain less information (such as Address Line 1, Postal Code and Country) – but the full address is preferred.
  • Item line information, to include:
    • Item Code/SKU
    • Item Description
    • Quantity
      • Weight and/or cube (optional)
      • Stock location (the depot in which the item is held)
      • On-hand date (this is the date the item is in stock and available for delivery, can be defaulted. If you are only passing orders in when the stock is ready to be delivered, then this can be set to a historic or today’s date)
  • Delivery Method (the fleet of vehicles completing the final mile delivery/collection, pre-defined in Stream)

Internal Stock movements

Often referred to as Trunking, internal stock movements can (optionally) be handled within Stream.

In the instance an order’s Stock Location does not match the Delivery Method (i.e. Item is held at “Birmingham Depot”, but fulfilled by “Manchester Vehicles”), the system will automatically generate an internal movement of goods before the final mile delivery can be planned.

Alternatively this could be handled outside of the system, prior to the order being created via the API.

Creating an order (Optional data set)

In addition to the above, there are also several optional fields which can be populated by using the API. Some of the more commonly used fields include:

  • Customer Reference Number (additional ref, does not need to be unique)
  • Customer Address – Optional, depending on who placed the order and formatted as per Collection/Delivery Address
  • Service Level (pre-defined in Stream)
  • Unload Time/Assembly Time (used to allocate on-site time for a driver at the point of delivery/collection. Can be held as a single time for the order, or stored per item line using the Item Assembly Time in the API.
  • Required Date (agreed delivery/collection date)
    • Required Time From/To, if also agreed
  • Notes – can be stored in multiple fields, depending on use:
    • Order Notes – stored for internal office use
    • Item notes – notes per item line
    • Location Instructions – used to store notes about an address, such as an access issue. Visible to the Driver via the Stream App.
    • Driver Notes – Notes for the driver, also visible via the Stream App.

Updating Orders

Updates to orders or order lines can be applied using the API endpoints.

There are a number of different API endpoints to apply updates, and it depends on the operational workflow, and what needs to be reflected in Stream, as to which endpoints to use. 

For instance there is the capability to ;

  • Update an Order (header and lines)
  • Update Order lines only
  • Update Order Groups (e.g. a Delivery / Collection leg)

Receiving notifications

With regards to status updates/information going back to your other system(s) (e.g. SAP Business one, Sage 200, WMS, etc.), this is optional, but when our subscribers use the webhook functionality to be notified of changes of state, they commonly register for Webhooks (such as Complete) and when they are received perform an action such as marking something off in the other system as being delivered.  

Checking for status changes

If you are not able to use Webhooks, a more manual way to be aware of changes of state would be to GET (Retrieve) Order status. This will provide the current orders status and a tracking link. Note: Checking for status this way can be manual and inefficient, hence why the webhook is preferred.

An order’s tracking URL can be returned and stored at the point an order is created via the API. 

This can allow users to access an order’s tracking / POD information via a link, from another system, without logging in to Stream.

Tracking info is returned at a number of stages in the lifecycle of the order, for instance when it is created however it can also be returned in the GET Order status endpoint.

API Support

If you need additional assistance integrating with your existing systems using our API, you can raise a ticket with our support team using the link below

Contact Support >

Was this article helpful?

Still need help?