canonical: https://jentic.com/apis/autodata-group.com/autodata

# Autodata Group Autodata API

Autodata supplies automotive technical data and repair information used by garages, parts retailers, and aftersales platforms. The current OpenAPI surface is intentionally small - three endpoints covering token issuance and a generic resource lookup - and is the authenticated front door to richer Autodata data sets that are loaded by resource ID. Integrators authenticate once with an API key, exchange it for an access token, and then list or fetch resources for the vehicle data they are entitled to.

## For AI agents

Authenticate with an Autodata API key to obtain an access token, then list available resources and fetch automotive technical data by resource ID.

## Scope

Does not handle vehicle telemetry, real-time diagnostics, or vehicle pricing - use for static automotive technical, repair, and fitment data only.

## Capabilities

- Exchange an Autodata API key for an access token via POST `/auth/token`
- List the resources entitled to the calling account with GET /resources
- Retrieve a specific automotive data resource by ID via GET `/resources/{id}`
- Drive entitlement-aware data access without enumerating per-vehicle endpoints
- Refresh the access token from the same `/auth/token` endpoint when it expires

## Use cases

### Garage management system data lookup

Embed Autodata technical data inside a garage management system so technicians can pull service intervals, torque values, or wiring diagrams next to the active job. The integration first calls POST `/auth/token` to mint a short-lived access token, then GET /resources to discover which data sets are entitled, and finally GET `/resources/{id}` to retrieve the specific document for the vehicle being serviced.

Example prompt: Mint an access token at `/auth/token`, list resources, then GET `/resources/{id}` for the resource ID matching the technician's current job

### Parts retailer fitment lookup

A parts retailer can match a customer's vehicle to compatible components by retrieving the matching technical resource from Autodata. The retailer's site authenticates once per session, lists the resources its plan covers, and pulls the specific fitment document by ID when the user selects a model. This avoids hosting and updating a fitment database in-house.

Example prompt: After authenticating, GET /resources to find the fitment resource ID for the selected vehicle, then GET `/resources/{id}` to fetch the document

### Agent-driven service planning

An AI agent helping a service advisor scope a job can fetch the relevant Autodata resource on demand. The agent searches Jentic for the technical data the advisor needs, Jentic injects the API key and access token, and the agent returns the document content to the advisor. Through Jentic the long-lived API key never enters the agent's context - only short-lived tokens move through it.

Example prompt: Use the access token to GET `/resources/{id}` for the service interval document and summarise the next required service for the advisor

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/auth/token` | Exchange an API key for an access token |
| GET | `/resources` | List entitled resources |
| GET | `/resources/{id}` | Retrieve a specific resource |

## Key resources

- **Authentication** — Exchange an API key for a short-lived access token
- **Resources** — List and retrieve entitled automotive technical data resources

## Why Jentic

- **Setup:** Wiring the Autodata API by hand means managing the X-API-Key header, running the `/auth/token` exchange to mint an access token, and refreshing it before it expires yourself. Through Jentic you install once, import the Autodata API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Autodata puts the resource id in the URL path (`/resources/{id}`), so a rule can pin your agent to reading one automotive data resource: it can fetch that resource and nothing else. You choose the operations it may call, so the token-minting call at `/auth/token` is not included unless you add it.
- **Credential handling:** Your Autodata X-API-Key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'fetch a vehicle data resource' or 'list Autodata resources', and Jentic returns the matching Autodata operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **CIS Automotive API** — CIS Automotive provides market and pricing data while Autodata covers technical and repair information
- **Smartcar API** — Smartcar reads live data directly from connected vehicles
- **Regrid API** — A different vertical-data provider - Regrid covers parcel and property records rather than vehicles

## FAQ

### Where does the OpenAPI specification for the Autodata API come from?

Jentic writes and maintains the specification used on this page. Autodata documents the API on its developer portal at `developer.autodata-group.com`, where the written reference and the interactive console both require an account, so a machine-readable specification cannot be retrieved without credentials. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Autodata API use?

Autodata uses an API key sent in the X-API-Key header on POST `/auth/token` to mint a short-lived access token. Subsequent calls to /resources and `/resources/{id}` carry the access token. Through Jentic the long-lived X-API-Key is held in the credential vault and only the short-lived token is used for downstream calls.

### How do I retrieve a specific resource from the Autodata API?

First POST to `/auth/token` with your X-API-Key to receive an access token. Then GET /resources to list the IDs your account is entitled to, and GET `/resources/{id}` to fetch a specific document by its ID.

### What kind of data does the Autodata API return?

Autodata covers automotive technical and repair information - service schedules, torque values, fluid specs, wiring diagrams, and component fitment. The OpenAPI spec exposes a generic `/resources/{id}` endpoint because the underlying data shape varies by resource type and entitlement.

### How do I look up automotive data through Jentic?

Search Jentic for 'fetch an Autodata resource', load the `/auth/token` and `/resources/{id}` operations, and execute them in sequence. Jentic chains the access token from the first call into the second. Get started with Jentic One, the self-hosted execution layer.

### What are the rate limits for the Autodata API?

Autodata sets rate limits per commercial plan rather than in the OpenAPI spec. `/auth/token` is lightweight and can be called frequently, while `/resources/{id}` reads are bounded by your data plan; if you receive a 429 response, back off and contact Autodata support for plan limits.

### Can I limit what my agent is allowed to do with the Autodata API?

Yes. Because you run Jentic One yourself, your own rules decide which Autodata operations and credentials your agent may use. Since Autodata puts the resource id in the URL path at `/resources/{id}`, you can pin the agent to reading a single automotive data resource so it fetches that one document and nothing else. You also choose whether the agent may call the token-minting operation at `/auth/token` or list resources with /resources, and any operation you leave out stays off limits.
