High level summary:
- Real-time updates from Shipwell through events and webhooks
- Added SLA conditions to contracts
- Force rerate (this time it actually made it to production)
- Orders moved to a new UI
- Mobile – iOS v3.2.2
- Various bugs addressed
API & real-time events
Events are our way of letting you know when something interesting happens in your Shipwell supply chain account. When an event occurs, we create a new event object. For example, when an order is created, we create a
purchase_order.created event; and when a carrier arrives at a location, we create a
shipment.timeline_event.created event. Note that many API requests, especially update requests, may cause multiple events to be created.
Event objects are created whenever a semantic event occurs in the system. This is commonly triggered by a change in the state of an API resource or sub-resource, but is not exclusively that. There are three common patterns of events we’ve currently identified and most events fall into one of these categories: object created, object updated, or object deleted. Since these three are so common, we have a common schema for sending them; all other events have an event-specific details section. These three types of events are easy to identify because they all end with
.deleted , respectively. The details of these bodies are outlined in the ‘Types of Events’ page.
As with other API resources, you can use endpoints to retrieve an individual event or a list of events from the API. We also have a separate webhook publishing system for sending the event objects directly to an endpoint on your server in real time.
Important note: Access to events through the retrieve event API is guaranteed only for 60 days. Older events may be available, but this is not guaranteed.
What are webhooks?
Shipwell uses webhooks to notify your applications any time an event happens for various supply chain milestones, updates, and predictive events. Set up webhooks for events that Shipwell doesn’t already notify you of, like when a shipment is in transit, or a customer goes over credit.
A webhook endpoint is like a function that Shipwell calls when certain things happen in your supply chain. Shipwell creates an event object for each occurrence in various objects that are worth notifying you about, like a shipment being delayed, or a payout to a carrier. Each event contains data explaining what happened.
When you create a webhook handler, it listens for specific events, then takes action whenever those events get sent to the endpoint. Technically, a webhook handler is just a script in a server-side language, like Python, C#, or Node, that handles any events you specify in the Dashboard. We add events weekly to the platform so if you don’t see an event you would like, send a request to firstname.lastname@example.org and we will add it.
Webhooks can also be used to provide state and API responses to services or systems that use Shipwell data for things like replication, analytics, alerting, or customer success.
When to use webhooks
Webhooks are necessary for behind-the-scenes transactions like the Shipwell events API and many alerting and long-running tasks in Shipwell. For many supply chain functions (like tracking an order or shipment), Shipwell needs to notify your integration about changes to the status of the object so that you can act on them.
Some Shipwell requests (e.g., tracking, tendering, or payments) generate results that Shipwell reports synchronously to your code. These integrations don’t require your verification, but the events allow you to share information with other systems. You can also use webhooks in these synchronous integrations to automate business tasks:
- Track an order or a shipment
- Email a customer when a shipment is delivered
- Create a notification to a carrier that they have been paid
- Make adjustments to an invoice when it’s created (but before it’s been paid)
- Create an alert when your routing guide is about to fail
We have updated our sandbox environment to include additional test data for the developer. When creating a sandbox for a company, there will be a test shipment, carriers, messages, line items, and associated charge line items. A developer can now get up to speed faster by having test data filled in for them.
|Shipment.timeline_event.created||Occurs when a timeline event is created|
|Shipment.timeline_event.updated||Occurs when a timeline event is updated|
|Shipment.status.updated||Occurs when a shipment status is updated|
- Added a fix for Teletracs authentication
- Added additional tracking providers to external status page
- Added a geosearch query that searches for all truck pings in a given radius of a given lat/long since a given datetime and aggregate those trucks down to carriers
- Resolved a bug in TriumphPay when deleting a carrier relationship
SLAs added to contracts
Service Level Agreements (SLAs) are now available as part of defining contracts that may impact the use of routing guide. SLAs help load planners and transportation managers identify a carrier’s expected capacity and acceptance rate.
Service Level Agreements (SLAs) capture agreed-upon terms similar to contracts but relate to the relationship between shipper and carrier including acceptance rate, capacity, awarded loads, and similar details that can be tracked. SLAs are linked to a contract that define details and rates for a specific lane.
(Defining an SLA)
Grouping contracts under SLAs
An SLA may be linked to multiple contracts where awards, acceptance, and other details may be spread over multiple lanes.
For example, a “Central/East TX” SLA may govern:
- Austin to Dallas
- Austin to San Antonio
- Austin to Houston
All lanes are covered under a single award and reported on as a single block – in this case, 8 loads per week, with a 90% acceptance rate, spread across all lanes.
(Linking a single SLA to multiple contracts)
A user working through the quote flow will no longer have the option to dismiss a re-rate if changes are made to the shipment after a rate has been selected. The option to ‘continue with booking’ has been removed from the ‘re-rating required’ pop up.
Order pages moved to new UI and window ranges for PU and DEL
New order page
The pickup & delivery section now allows the user to enter a day/time range for both the pickup as well as the delivery.
- Both the start and the end fields are required
- One end of the range can be entered and the other can be blank
- A pickup range can be entered without a delivery range and vice versa
- The start date within a range must be before the end date of the range
- If both the pickup and delivery fields are populated, the delivery must come after the pickup
Clicking in one of the fields will present the user with a calendar and time selector.
The line item section has been updated to use collapsible functionality. When the user lands on this page initially, item 1 is expanded and the fields are made available. If the user chooses to add an item (+ item), the first item entered will be collapsed and the fields for the second item will display.
The user will see the product description for each collapsed item. To expand the item click on the down arrow.
Order details page
When the user accesses the order details page, all items that make up the order will be collapsed. To view the details, click on the down arrow.
The order table has been updated to display the ranges in both the pickup and delivery columns. In the example below, a range was entered for pickup and delivery was left blank.
Email and rate consent via email when tender is accepted
When a carrier accepts a tender for a shipment, the following two emails are sent:
- An email is sent to the shipper with notification that the shipment has been accepted by a carrier
- An email is sent to the carrier with notification that the shipment has been awarded. This email will also contain the rate confirmation
Mobile - iOS v3.2.2
- App now displays an alert banner when there is no network connection
- Improvements to tracking, dark mode, and document updates
- Added pagination support to messages
- Fixed a condition preventing assignment of unassigned shipments when user has both driver and dispatcher profiles active
Various bugs addressed
- SLUs are no longer able to see messages from other users within the same company. SLUs can only see those messages they sent and messages sent from the customers
- Modifications have been made to limit the email notification that is sent out when a load is booked to the person that booked the load rather than all of the contacts listed for that company