The Ryder Last Mile API is intended for Last Mile customers to manage orders and order status.
Refer to the API Overview page to access the API Specification.
This guide covers:
Getting Access
Environments & Authentication
Use Cases
To use the Carrier API, testing should be completed in the Test Environment before moving to Production. Follow the steps below to request access in Ryder's Production Environment, and upon approval, you'll be provided credentials for both the Production and Test Environments.
1. Go to https://developer.ryder.com to access the Production Environment.
2. Click on Sign up and complete the form.
3. In your email inbox, open the verification email from no_reply@ryder.com, and click "Verify."
4. You will be redirected to sign in. Confirm that you can log in.
5. Navigate to My Account> My Apps.
6. Create an application.
App Name: Insert your company and app name.
Oauth Redirect URL: Leave Blank.
API Product: Select "SCS Carrier API."
7. On first login, you will be required to review and accept the Developer Terms of Service.
8. At this point, notify your Ryder contact that you have requested access, and are awaiting approval.
9. Once approved, you will receive an email from developer_notifications@ryder.com.
10. Access your Production API Key in My Account> My Apps. Your Test Key will be provided separately by Ryder.
Production: https://api.ryder.com/rcsc/events/v1/
Testing: https://apiqa.ryder.com/rcsc/events/v1/
The API uses an API key for authentication, in addition to a required SCAC identifier. These headers should be included in the request as follows:
POST /rcsc/order-requests/v1/ HTTPS/1.1
Host: api.ryder.com
Ocp-Apim-Subscription-Key: your_api_key_here
Accept: application/json
Refer to these documents for more information on the order payload:
POST Order-Requests (New Orders)
QA post statement - POST https://apiqa.ryder.com/rcsc/order-requests/v1/
Supply JSON file into body and then send
Save ‘ID’ sent back in the response. This ID should be linked to the order and will be needed to be sent on any update or cancel to the order number.
Example ID number format - 638c33fd-244d-4e18-ad8b-e22359c780x2
PUT Order-Requests (Update Orders)
QA put statement - PUT https://apiqa.ryder.com/rcsc/order-requests/v1/638c33fd-244d-4e18-ad8b-e22359c780x2
This is used to update the following information on an order already in the Ryder System’:
Shipper Code
Consignee Details – Address, phone, email updates or additions
Delivery Type – Change in level of service for delivery
Add comments – Internal to Ryder or for the Delivery Team
References – Add additional reference numbers
Increase or decrease SKU quantity as long as entire order is not cancelled.
Supply JSON Updated file (new full complete order with all changes)
Update JSON file should contain order ID in file and also in PUT statement.
DELETE Order-Requests (Cancel Order) – Cancels entire order
QA delete statement – DELETE https://apiqa.ryder.com/rcsc/order-requests/v1/638c33fd-244d-4e18-ad8b-e22359c780x2
No json supplied. Send delete request ID only.
STATUS Order-Requests – Supplies status of most recent action
QA Status of Order-Requests – GET https://apiqa.ryder.com/rcsc/order-requests/v1/638c33fd-244d-4e18-ad8b-e22359c780x2 /statuses
Refer to these documents for more information on the status payload:
There are 3 primary uses for the polling information from the Ryder API.
1. orderHistory Batch – Plan on using this poll as it is best designed for your needs. This poll can be run on a schedule to retrieve changes to order events since your last batch poll. Your getStatement in QA would be:
https://apiqa.ryder.com/rcsc/order-status/v1/orders?partnerId=TBD&clientId=TBD
2. orderHistory single – This type of poll is best used for a single inquiry for an order by a customer service representative who may need to know the current status or history of a single order for research. This would be a poll similar to this:
https://apiqa.ryder.com/rcsc/order-status/v1/orders?orderRef=1234567 {client facing order number or secondary reference number}
3. orderStatus – Provides ‘Milestone’ status only. Best used for linking our API to an end-consumer portal. For example, the end-consumer is provided a link by you and when they click ‘Track My Order’ they would receive high-level status update. Example poll statement:
https://apiqa.ryder.com/rcsc/order-status/v1/tracks?orderRef=1234567 {client facing order number or secondary reference number}
You can link their order number to be inserted into last element (1234567) so when they click the link, they receive the most current ‘MileStone’ of their order history.
Usage Notes:
RLM far prefers that our clients use option 1 above to auto poll for data. Using an example that you have 1000 open orders in the Ryder system - Reduces the amount of polls per day and eliminates the duplication of information retrieved for your system to parse.
If you set your poll to run every 30 minutes and poll for each order using orderHistory single (2 above) on each run, you would be reaching out to our API 48,000 times a day. Many of the polls would retrieve the same data that you have already received as each order does not move so quickly to have new statuses at this rate of poll.
If you set your poll to run every 30 minutes and poll for a batch using orderHistory Batch (1 above) on each run, you would be reaching out to our API 48 times in a day. The information retrieved would be unique to orders that have had a new event that occurred since your last pull.