Making it easy to connect your back office with Stream

We sat down with our Head of Product (and in-house API expert) Shahid Latif to talk about what’s new with the API and Webhooks – and where it’s heading.

But, before we start… just, what is an API?

Well, it stands for Application Programming Interface. An API is just a little bit of code, which is ‘encapsulated’ to facilitate communication between applications.

Shahid introduced us to APIs and Webhooks, as a way to “make it a lot easier to integrate with Stream, so your other systems can communicate a lot more easily, sending information in, and getting alerts and updates back”.

What’s new with the Stream API?

In a nutshell, we’ve added a few more endpoints.

So you’ve got the Stream API and within the API you’ve got certain ‘services’ or ‘endpoints’.

Recently, the development team has been adding more endpoints to the API so users can now delete orders and update certain orders in a more logical and efficient way.

We’ve also added a considerable amount of functionality in the API around items. As well as actually creating the item and adding a single item, you can now update and delete items as well.

Shahid also provided some detail around ‘delivery groups’ and ‘legs’ that have also been added to the API:

“When you’ve got an order that needs delivering from A to B, that’s a single-leg, as in a transport leg. Potentially you could have more than one. So you could have a collection leg and a delivery leg or multiple delivery legs because there’s a lot of things to deliver and they’re all related to the same order. With the latest versions of the Stream API we’re now enabling a transport leg to be updated, whereas previously it would have been the whole order and just the items.

“You could update it throughout the process, at different times of the process, but what you were looking at was the order as a whole, whereas now you can look at the individual transport legs and make updates to that as well. For some subscribers, that’s more relevant because that is applied in the planning. When you’re planning, you’re actually planning at leg level (at transport leg level) rather than the order level. So even though it looks like that on the route planning screen, you’ve got a lot of orders that you want to deliver, what you’ve actually got is a number of legs that you want to plan. That could be a delivery, a collection or a combination. By bringing additional levels of integration capability, we’re giving subscribers more flexibility.”

And as for getting information and updates back into Stream?

“Latest versions of the Stream API enable more webhook triggers related to those legs as well. So, when I’ve put something on a run – not before I’ve actually delivered it, but when I’ve planned it – I can then set up triggers so I can take actions in another the system. So for some subscribers, that type of scenario would be: I’ve put a whole lot of deliveries and collections on a plan, before I pass them on to my driver I want them to be picked. Now, the picking, from the warehouse would be done in another business system, so it’s that other system that needs to know: they’re now ready to be picked. So pick them, then load them onto the vehicle, then deliver them. So those stages are now more visible to other systems.

“It increases the different scenarios the system can be used in. It can help other systems be aware of what’s happened with that order, what they need to do in another part of the business, and also what’s happening in regards drivers and runs and whatever. Because Stream, at the end of the day is focusing on the delivery and logistics side of things, whereas other systems, like your organisations ERP software, is doing much more within the business. And to keep that system in sync or more informed, you need more granular information going between the two systems.”

Making the synchronization between different systems is a lot tighter

With the updated version of the Stream API you can keep more of it up to date at more points throughout the lifecycle of a particular order as it comes in, as it gets delivered, as it gets picked, whatever it might be.

“We started with the basics” explains Shahid.

“We started with ‘create an order’ or maybe ‘add a line’ and that was it. Well, throughout the process you might be doing more than that. You might need to remove a line because that’s no longer available. But how do you know it’s no longer available? Well, the other system knows it’s no longer available. So that will make the decision, that will then tell Stream that that line needs removing. What you bring into Stream normally is things like the order information, and by that, I mean things like, delivery addresses, contact details, account details. You’ve got things like any specific items that are on the order, when there might be a particular requirement, but that’s all to do with the order itself. The order, and then that’s the individual items within the order.

“And then, if you’re using the API at least, you would have the webhooks triggering throughout the lifecycle of that order, through its generation in Stream, through its planning, through its delivery, through its revision of planning or ePOD, as soon as the driver marks off that it’s been delivered, it would then trigger a webhook.”

The Webhook is effectively an alert, so it’s going to any other system that’s listening to it: ‘oh, that item has been delivered’. The idea then is, you decide in whichever system you want, what you want to do about that. So if it’s delivered, let’s for argument say in Stream, your ERP system might need to mark off the fact that it’s completed.

So you’d use the Stream API’s webhook that way. But there’s a whole multitude of those webhooks. They could be used when an order is planned or when it’s taken off a plan or when it’s been loaded onto the vehicle. Those all those trigger points can be seen by other systems and then acted upon.

As far as information and updates coming from Stream into another application? What we tend to do is give information around the order status.

If it’s been delivered, it’s been collected for instance.

“We can also pass back data such as driver information or the run that it’s on, but that’s just getting very specific then. I would always class that as order information, transport leg information that is all coming in. But then going out is really your ability to find ways to pull out status information to do with a particular order, even item level as well, because it may be that some orders and some parts of the order are delivered, some aren’t delivered. What we tend to do is focus on those webhooks. So you set the alert and then the alert,  you then decide on that other system what you want to do about that alert. Then you pull back, what we call the order status or additional information.

“It’s very much pushing in as much as you can in Stream and then taking out information when or if you need it. If someone wants to know about our API, the Stream API documentation is a resource that you can access from this website.”

 


Access the Stream API documentation for yourself here and email support@go2stream.com to create a developer account for your company.