Integrating Your Existing Systems With Stream Using the Stream API

Posted by Rob Spivey on January 3, 2023

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

In the majority of cases, a one way integration is sufficient, for the purpose of creating orders in Stream, 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.

In this article:

    1. Typical Data Flow Between Stream and Your Existing System
    2. Stream API Documentation
    3. Creating an order (Recommended Data Set)
    4. Creating an order (Optional Data Set)
    5. Updating Orders
    6. Receiving notifications
    7. Providing Tracking Links (URLS) and Tracking IDs

 

Typical Data Flow Between Stream and Your Existing System

Using the Stream API, you can automate the creation of orders in Stream.

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:

 

Stream-API-Workflow-Using-Typical-Existing-Systems

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 Stream API services are available and can be discussed with the Stream support team to agree on the best approach.

 

Stream API Documentation

You can view the Stream API Documentation using the link below.

View Stream API Documentation >

 

The minimum order information, required to be provided to Stream 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 from Stream.
  • 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 in Stream. If you are only passing orders in to Stream 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”), Stream will automatically generate an internal movement of goods before the final mile delivery can be planned.

Alternatively this could be handled outside of Stream, prior to the order being created.

 

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 to Stream 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 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 into 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.


Stream API Support

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

Contact Support >

Didn't find what you're looking for?

Still can't find the answers you're looking for? Contact our support team