Integration API - Release Notes

Integration API - Release Notes

Version 1.17
  • Consignments will get rejected if the courier brand is unable to deliver the freight due to disruptions in the network.
  • Added service-availability endpoint to check whether we are able to deliver freight to a destination for a given service type.
  • Improvements to the email validation regex to capture invalid email addresses.
Version 1.15
Updated the email validation to only allow valid email address characters.
Version 1.13
The receivers email address is now optional rather than mandatory.
Version 1.12

Provide enough information in response to creating a consignment to allow a user to create their own label.
 
Information that has been added:

  • Human readable barcode string
  • Delivery branch code
  • Delivery run
  • Non Urban flag
Version 1.11

Corrected response Consignment Cancellation type

The response type was incorrectly defined in the spec and did not match actually what was being returned. The api specification has been updated from application/json to text/plain in the endpoint:

/v1/carriers/{carrierName}/customers/{customerId}/consignments/{consignmentId}/cancellationrequests

This update is purely in the documentation and there has been no change to the API itself.

Version 1.10

Sender and Receiver Contact Details and Rate Calls

pickupAddress and deliveryAddress are now mandatory but also removed address portion, just lat\lon are required.

Example:

{
"lon": 172.572266,
"lat": -43.531668
}

Address Format

Added secondary address line to address object for consignments

  • Both street and secondary address lines are shown on the label as a single line.
  • A warning is returned if the address may not fix on the label.
  • AddressRight line 2 is mapped to the new secondary address field when returning an address object.

Field Lengths

Lengthened the following fields to 80 characters:

  • street
  • suburb
  • town
Version 1.9

Receiver Contact is no Longer Mandatory

The contact field in the consignment is no longer mandatory

eventType Values are Consistent

The TrackingEvent eventTypes were inconsistent in some had values and others had codes, the values are as follows

  • Picked Up
  • Delivered
  • Non-Delivery
  • Label Created
  • Permission to Leave
  • Status

These values only apply to the TrackingEvents, the notification eventType are different.

No Split Delivery

No split delivery can be requested when creating a consignment, a new property noSplitDelivery has been added. This defaults to false.

Version 1.4

Phone Numbers

Phone number validation regex patterns are now consistent and have a minimum and maximum length.

ConsignmentItem itemReference

Was previously used to specify both the itemReference and the part number, now the part number is automatically assigned so it now performs a single role as such:

  • Is now an alphanumeric string rather than an integer
  • The itemReference is no longer a mandatory field
  • Base+ consignment items accept an array of itemReference strings allowing the different parts to be assigned unique references
Version 1.3

Tracking Events for Consignment

The tracking events can now be queried for a consignment, two endpoints are available, the tracking-events endpoint will return all the events for a consignment item between two optional dates. The attachments endpoint will return an image for a tracking event.

/v1/carriers/{carrierName}/customers/{customerId}/consignments/{consignmentId}/items/{consignmentItemId}/tracking-events
/v1/carriers/{carrierName}/customers/{customerId}/consignments/{consignmentId}/items/{consignmentItemId}/tracking-events/at
Version 1.2

Pagination

The pagination details returned as part of a collection have been changed from:

Old

    "limit": 10,
    "size": 10,
    "skip": 0

New

    "totalItems": 1435,
    "pageSize": 10,
    "page": 2

Consignments

  • ConsignmentStatus: Search based on status can now take a comma separated collection of different statuses to search on.
  • Unvalidated Addresses - Latitude and Longitude are now optional and Freightways will attempt to validate the address for you, if it is unable to then the consignment will be rated based on the suburb if that can be identified. An unvalidated address may attach further charges as the exact address cannot be identified
    • isSaturdayDelivery - flag identifying whether Saturday delivery was accepted and rated for is returned. The request for Saturday delivery will be ignored for unvalidated addresses.

In the response to a Consignment creation, we may return warnings about how we created the consignment to indicate that the rate is an estimate only and after the fact charging may be levied.

  • Notifications: A new Notifications model is used to define notifications.
  • Address and latitude and longitude have been replaced by an Address model giving consistency across all the resources using addresses

Rates

  • Support for unvalidated addresses: In the same way Consignment creation has now support for unvalidated addresses, you can now rate an unvalidated address and the latitude and longitude in the request are now our standard Address model.
  • Service Standard can be requested in the rating request: e.g. ‘TWO DAY’

In the response to a rating request we may return warnings about the response to indicate that the rate is an estimate only and after the fact charging may be levied.

AddressRight

  • AddressRight is now implemented behind the Customer Integration
/v1/addressFuzzy
/v1/addressMatch
/v1/addressAutocomplete
/v1/addresses/{addressId}


The 3 different search methods are supported, each returns a collection of addresses strings and an AddressRight Id. The /v1/addresses/{addressId} can be used to exchange the Id for an address object which can be used in rating and consignments.

Pickup Requests

  • Pickup requests via pin number now supported
pickup-requests/address
  • pickup-location-pickup-requests renamed to pickup-requests/pickup-location
 

    • Related Articles

    • Integration API - Technical Documentation

      In this Technical Documentation: Open API Specification Example Scenarios Getting Connected Code Snippets Selecting Carrier and Customer Date and Time Handling AddressRight Sequence Diagram Open API Specification View the Customer Integration Open ...
    • Integration API - Terms of Use

      The Terms of Use for our API are located on the Freightways website (our parent company). Click to Zoom View the Terms of Use for our API >
    • Integration API - Address Validation Logic

      This article explains the logic behind how we validate your addresses through our API and what could be causing your API error when generating a consignment. Address Validation Logic Process Our Address Validation logic works based on the process of ...
    • API FAQ's

      This article contains the most frequently asked questions that our Customer Integration team receive: Shipping with the New Zealand Couriers / Freightways API's Use of Latitude and Longitude Outages/Troubleshooting Before Going Live Shipping with the ...
    • API Uptime & Monitoring

      New Zealand Couriers' API Uptime monitoring can be found at https://status.nzcouriers.co.nz/.