
On this page
- What VinAudit Market Listings data covers
- What data is available in each listing
- How listings can be searched and filtered
- How active, in-transit, and dropped listings should be interpreted
- Listing history, price history, and days seen
- U.S. and Canadian coverage and units
- How Market Listings data can fit automotive workflows
- Market Listings API versus Total Market Feed
- Access, updates, and data limitations
- Next steps
Automotive listing data can answer more than whether a particular vehicle is currently advertised for sale. When listings are structured by vehicle configuration, seller, geography, price, and listing history, they can support workflows ranging from comparable-vehicle searches to inventory analysis and pricing applications.
VinAudit’s Market Listings product provides access to retail vehicle listings across the United States and Canada. The Market Listings API is designed for applications that need to query specific subsets of this data, while broader market-data access can support workflows that require larger datasets.
This guide explains what VinAudit Market Listings data covers, what fields and filters are available, how listing status and history should be interpreted, and when API or bulk-data access may fit different automotive workflows.
What VinAudit Market Listings data covers
The VinAudit Market Listings API provides access to U.S. and Canadian retail vehicle listings through the /v1/listings endpoint. Requests can be made using GET or POST and require an API-enabled account and API key. JSON is the default response format, with XML also supported.
The dataset combines information about the vehicle, listing, seller, pricing, mileage, location, and observed listing activity. This allows clients to search the market in several ways, including by vehicle configuration, reference VIN, dealer, geography, price range, and listing status.
Market Listings is therefore not limited to a basic inventory lookup. The API can support both current-inventory queries and analysis of documented listing-history fields.
What data is available in each listing
Market Listings responses can include several categories of information that work together in downstream applications.
Vehicle information
Available vehicle attributes can include year, make, model, trim, style, vehicle type, engine, fuel type, transmission, drivetrain, and other specifications where available.
The API also supports VinAudit specification identifiers. A spec_id can represent different levels of vehicle configuration, while spec_vin allows a reference VIN to be used when searching for similar vehicles.
These options allow a client to search more precisely than using make and model alone.
Listing information
Documented listing fields include information such as:
- VIN, when available
- Listing title and description
- Listing type
- Mileage
- Latest advertised price
- Listing status
- Seller stock number
- Vehicle detail
pageURL
The response also includes fields that describe when a listing was observed and how its advertised price changed over time.
Seller and location information
Seller-level information can include a VinAudit seller ID, seller type, dealer name, address, city, region, postal code, country, latitude, longitude, and other available seller information.
These fields can be combined with geographic query parameters to examine inventory associated with a particular seller, location, or surrounding market.
How listings can be searched and filtered
The Market Listings API provides more than 20 documented search parameters, allowing clients to narrow results before retrieving them.
Vehicle-based searches can use criteria such as:
- VIN
- Make
spec_id- Reference VIN through
spec_vin - Vehicle type
- Fuel type
- Transmission type
- Drivetrain
- Other documented vehicle attributes
Queries can also apply minimum and maximum price or mileage criteria and distinguish between listing types where supported.
Geographic searches can use postal code, latitude and longitude, city and region, or a radius around a location.
Seller-level filtering can use seller_id and other documented criteria, making it possible to analyze inventory for an individual dealer or combine seller and geographic restrictions.
For comparable-vehicle workflows, spec_id and spec_vin provide more targeted ways to define the relevant vehicle configuration.
Choosing a vehicle search parameter
| Parameter | Search purpose |
|---|---|
vin |
Find listings for a specific VIN |
spec_vin |
Use a reference VIN to find similar vehicles |
spec_id |
Search by a vehicle configuration |
When both spec_id and spec_vin are supplied, spec_id takes precedence.
Example: search a local market
This illustrative request combines a vehicle configuration with a U.S. postal code and a 50-mile search radius.
curl --get 'https://marketlistings.vinaudit.com/v1/listings' \
--data-urlencode 'key=YOUR_API_KEY' \
--data-urlencode 'spec_id=2021_tesla_model-3_long-range' \
--data-urlencode 'postal=30680' \
--data-urlencode 'radius=50' \
--data-urlencode 'country=usa' \
--data-urlencode 'format=json'
Replace YOUR_API_KEY with your account’s API key. This example has not been executed.
How active, in-transit, and dropped listings should be interpreted
Listing status is important when Market Listings data is used for inventory or historical analysis.
The API documents the following statuses:
- Active: recently listed for sale within the documented active period
- In-transit: listings associated with vehicles pending sale due to transportation
- Dropped: vehicles no longer actively listed for sale
Queries can request supported statuses individually or in combination.
A dropped listing should not automatically be treated as a confirmed vehicle sale. The documentation describes dropped vehicles as no longer actively listed and likely sold, but disappearance from an online listing does not itself verify that a transaction occurred.
This distinction matters when the data is used for sales-rate analysis, valuation, inventory turnover, or other downstream calculations.
Listing history, price history, and days seen
The API includes several fields that help describe the observed lifecycle of a listing.
These include:
| Field | Documented meaning |
|---|---|
listing_date |
when the listing was first observed |
date_max |
the most recent date the listing was observed |
date_dropped |
when the VIN was confirmed as no longer listed |
days_seen |
the number of days the listing was observed online from first to last sighting |
price_history |
dated changes to the advertised listing price |
When dropped listings are included, history_days controls how far back the query looks for historical records.
These fields can support analysis of listing duration and advertised-price changes, but their documented meanings should be preserved in downstream applications.
In particular, days_seen should not automatically be renamed or interpreted as “days on market.” It specifically represents the number of days the listing was observed online from its first to last sighting.
Likewise, a listing being dropped does not establish that the vehicle was sold.
U.S. and Canadian coverage and units
The Market Listings API supports retail vehicle listings in both the United States and Canada.
The country setting affects how certain values are represented:
- U.S. requests use USD for prices and miles for distance.
- Canadian requests use CAD for prices and kilometers for distance.
This distinction is especially important for geographic and radius-based searches, pricing analysis, and applications that combine results from both markets.
Applications working across the two countries should preserve the appropriate currency and measurement context instead of treating the datasets as directly interchangeable without normalization.
How Market Listings data can fit automotive workflows
The usefulness of listing-level market data depends on the question a system needs to answer.
Valuation and appraisal
Valuation and pricing applications can search for vehicles with similar configurations and geographic characteristics to assemble comparable advertised listings.
Price history and listing-history fields can provide additional context around those vehicles.
Dealer and inventory software
Dealer tools can examine surrounding inventory, identify comparable listings, and compare a dealer’s advertised vehicles with others in the same market.
Automotive marketplaces
Marketplaces and consumer applications can use vehicle and geographic filters to support inventory-search experiences and surface similar vehicles within a specified area.
Market analytics
Analytics systems can organize listings by geography, make, model, configuration, seller, or other documented fields to examine inventory and advertised-price patterns.
Automotive software and data products
Software and data teams can incorporate listing information into broader vehicle-data workflows, including applications that combine market listings with specifications or other vehicle information.
These workflows should preserve the limitations of the underlying listing signals. For example, a dropped listing indicates that the vehicle is no longer actively advertised, not that a completed sale has been verified.
Market Listings API versus Total Market Feed
The appropriate access method depends on how much data a workflow needs and how that data will be consumed.
The Market Listings API is designed for query-driven access. Applications can request selected listings using vehicle, seller, pricing, location, status, and other documented filters and receive paginated results.
This model fits workflows such as:
- Comparable-vehicle searches
- Dealer or geographic inventory queries
- Application features that retrieve selected listings
- Targeted market analysis
The Total Market Feed is the related option for workflows that require broader or bulk access to market-listing data.
Rather than assuming that one method is preferable based only on volume, prospective users should evaluate how frequently they need data, how much of the market they need to process, and whether they need targeted query responses or a broader dataset for their own processing environment.
Specific Total Market Feed delivery methods, refresh schedules, and large-scale access arrangements should be confirmed against current VinAudit product information before publication or implementation.
Access, updates, and data limitations
Market Listings API access requires an API-enabled account and API key.
Results are paginated using page_size and page. Response metadata includes information used to understand the number of matching records and navigate across result pages.
Clients should also account for variation in listing records. A VIN, seller attribute, vehicle specification, history value, or other field may not be available for every listing.
Listing status and history also need to be interpreted according to their documented definitions. An active listing represents recently observed advertised inventory, while a dropped listing represents inventory no longer actively listed rather than a confirmed transaction.
VinAudit Market Listings lets you search U.S. and Canadian retail vehicle listings by vehicle, dealer and location. Results include listing status and history fields to help you understand when a listing was observed. Contact VinAudit to confirm data freshness and update frequency for your use case.
For the complete parameter list, response schema, field definitions, and current API behavior, refer to the VinAudit Market Listings API documentation.
Teams considering broader market-data access can also review VinAudit’s Total Market Feed offering and discuss their expected data requirements with VinAudit.
Next steps
Teams evaluating Market Listings should start with the API documentation to review the available parameters, response fields, and listing-status definitions against their intended workflow.
For applications that need targeted listing queries, the Market Listings API provides programmatic access to filtered U.S. and Canadian retail listings. For workflows requiring broader market-data access, VinAudit can help determine whether a bulk-data option is more appropriate.