To get live API access, your integration must pass certain tests. This will make sure that it meets our technical standards and best practices.
For each capability, the tests cover Essential and Enhanced functionalities. Your integration must pass at least one of the Essential functionality tests to get live access.
We recommend using the Enhanced functionalities to allow dealers to get the full benefits of the service.
We'll cover the tests for the following functionalities:
- Deal update notifications (Essential)
- Baseline deals (Essential)
-
- View deals list (Essential)
- View individual deal (Essential)
-
- View deal part exchange (Essential)
- View deal delivery (Essential)
- View deal finance application (Essential)
There are three ways we check that tests are successful:
- Demonstration - We will expect you to show us your code or your UI
- Call log validation - We will check your API calls to our service to make sure the call is made correctly
- Database check - We will check our database to see whether the correct attribute has been updated
Deal update notifications (Essential)
In order to keep your Auto Trader deals up-to-date, you will need to make sure you are successfully updating your deals based on deal update notifications that are sent to you.
Hash authentication
| Test | How we'll check it |
| Implemented hash authentication on your notification endpoint and return a successful response code (2XX) if the hash authentication matches | Call log validation |
| Able to identify the notification type of DEAL_UPDATE to know to update deals with this notification | Call log validation |
| Optional Checks | |
|
Implemented hash authentication on your notification endpoint and return a forbidden response code (403) if the hash authentication does not match |
Call log validation |
Deal created
You'll get a webhook when a deal is created for a dealer on your integration after a consumer completes the Deal Builder journey on the Auto Trader website. You need to handle this and create a deal in your system to match.
| Test | How we'll check it |
| Successfully able to create an Auto Trader deal in your system when a deal is submitted via Deal Builder on Auto Trader | Demonstration |
|
Able to store essential deal identifiers from the webhook notification:
|
Demonstration |
|
Able to store the price of the deal. This is the price the deal should be fulfilled for, not the price that the vehicle is currently listed for on Auto Trader |
Demonstration |
|
Able to identify whether the deal has been reserved on Auto Trader, and is available to the consumer, by checking the reservationStatus and availabilityStatus attributes |
Demonstration |
Deal availability and status
You'll get a webhook whenever the deal's availability is updated. The deal may no longer be available for the consumer, or it may be completed or cancelled.
| Test | How we'll check it |
| Able to identify if the vehicle is no longer available to the consumer when reservationStatus is set to “Reserved”, but availabilityStatus is set to “Not Available” | Demonstration |
|
Successfully update deal status to cancelled if either advertiserDealStatus or consumerDealStatus is set to “Cancelled” |
Demonstration |
|
Successfully update deal status to completed if either advertiserDealStatus or consumerDealStatus is set to “Completed” |
Demonstration |
Component updates
You'll get a webhook when any components are added to a deal or any components are updated. The details of the components won't be included in the notification though, so you'll need to call their respective APIs to get the updated details.
| Test | How we'll check it |
| Able to identify if any components have been added to the deal if a component ID is now on a component that did not have a component ID previously | Demonstration |
|
Able to identify if any components have been removed from the deal if they are now set as null in the notification when previous notifications did have a component ID |
Demonstration |
|
When you get a deal update notification, you must call each of the component endpoints below, where a component ID is present in the deal object:
|
Call log validation |
|
Able to identify any changes to the components after calling each endpoint |
Demonstration |
Baseline deals (Essential)
You need to call the Deals API to get the current deals in Auto Trader for a dealer, to then pull into your system. This will allow the deal update notifications to keep your deals up-to-date.
View deal list (Essential)
You can fetch all deals for a dealer by doing a GET request on the Deals API including the advertiser ID and pagination in the query string of the request.
| Test | How we'll check it |
| Get deals for a single dealer using the advertiserId parameter | Call log validation |
|
Paginate through deals when total results are greater than the page size requested |
Call log validation |
|
Store essential deal identifiers, deal ID and component IDs, within the deal object |
Demonstration |
|
If you receive a 403 response code from the Deals API, you should not retry the call for this advertiser ID, and log the error somewhere, with an action to contact Auto Trader if incorrect |
Demonstration |
View individual deal (Essential)
You can also view an individual deal by doing a GET request on the Deals API with the deal ID in the URL.
| Test | How we'll check it |
| Able to perform a GET on the Deals API with deal ID in the request path to get the deal object for a specific deal ID, and advertiser ID in the request query string | Call log validation |
|
If you receive a 404, you should not retry the call and mark the deal as deleted in your system. This means the deal ID no longer exists in Auto Trader. |
Demonstration |
View part exchange (Essential)
When a part exchange component is included in a deal, you should use the Part Exchange API to get details about the part-exchange vehicle the consumer wants to include.
| Test | How we'll check it |
| Able to call the Part Exchange API with the part exchange component ID to get part exchange details of a deal | Call log validation |
|
Calls should not be on a schedule, and should only be called when you receive a deal update notification, or when you are baselining a deal |
Call log validation |
|
If you receive a 404, you should not retry the call and remove the part exchange component from the deal, as the component is no longer attached to the deal |
Demonstration |
View finance (Essential)
When a finance component is included in a deal, use the Finance API to get details about the consumer's finance application and the finance proposals made by lenders.
| Test | How we'll check it |
| Able to call the Finance API with the finance application component ID to get finance application details of a deal | Call log validation |
|
Able to call the proposals endpoint of the Finance API with the finance application component ID to get all of the finance proposals for a finance application |
Call log validation |
|
Identify the active proposal on a deal, and present this to the user |
Demonstration |
|
Calls should not be on a schedule, and should only be called when you receive a deal update notification, or when you are baselining a deal |
Call log validation |
|
If you receive a 404, you should not retry the call and remove the finance application component from the deal, as the component is no longer attached to the deal |
Demonstration |
View delivery (Essential)
When a delivery component is included in a deal, use the Delivery API to get details about the delivery option the consumer has selected as part of this deal.
| Test | How we'll check it |
| Able to call the Delivery API with the delivery component ID to get delivery details of a deal | Call log validation |
|
Calls should not be on a schedule, and should only be called when you receive a deal update notification, or when you are baselining a deal |
Call log validation |
|
If you receive a 404, you should not retry the call and remove the delivery component from the deal, as the component is no longer attached to the deal |
Demonstration |