This is the description of the *Stellantis Connected Car V2 API*. The speccification is is based on **OpenAPI Specification version 3** and can be displayed using [ReDoc](https://github.com/Rebilly/ReDoc) or [Swagger](http://swagger.io).
Every API here is available over the APIs.io API and to AI agents over MCP.
One button, every client — Claude, Cursor, VS Code and the rest.
https://apis.io/mcp
find_apisBrowse and filter every API in the catalog.get_api_artifactsOne API's artifacts, grouped by type.get_openapiThe primary OpenAPI for this API.find_similar_apisAPIs that look like this one.apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.resolveTurn a domain, URL or GitHub org into the provider it belongs to.find_cohortsEvery scored population of providers in the catalog.curl "https://apis.io/api/v1/apis/stellantis:stellantis-data-treatment-api"curl "https://apis.io/api/v1/apis?limit=25"Discovery needs no key. Ratings and market analysis are Pro.
Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.
A second provider on the same verified email joins the account you already have.
openapi: 3.0.0
servers:
- url: https://server/api/connectedcar/v1
info:
version: '1.0.28'
title: Stellantis Connected Car API
description: |
*Connected Car API*
# Introduction
This is the description of the *Stellantis Connected Car V2 API*. The speccification is is based on **OpenAPI Specification version 3** and can be displayed using [ReDoc](https://github.com/Rebilly/ReDoc) or [Swagger](http://swagger.io).
This API allows applications to fetch data from the Connected Vehicles Data Platform. It is designed to be **a declarative data and function specification**, so they are understood and consumed by stakeholders without knowledge of manufacturer onboard vehicle specification
---
# API features
## Vehicles:
<i>Access to static vehicle resources such as brand, description and images as well as the IoT data.</i>
## Trips:
<i>Access to the trips traveled by the vehicle and their data such as telemetry, alerts and waypoints, etc.</i>
## Channel:
<i> Definition of an output channel that can be used as a return channel for the Monitor and Remote functions or as an output for the datastream.</i>
## Monitor:
<i>Creating a monitor with several flags that define a logical expression that is the exact functional condition for triggering the monitor. It is also possible to define the actions (remote action or monitor changes) to invoke when receiving a particular monitor event. Thus, it can be possible to automate scenarios.</i>
## Remote:
<i>Send the remote command to the vehicle. It is also possible to define the actions (remote action or monitor changes) to invoke when receiving a particular remote event channel status. Thus, it can be possible to automate scenarios.</i>
## Datastream:
<i>Create output data streams on a defined channel. Data sent on this stream are the same as that exposed by the APIs.</i>
---
# API Authentication
Stellantis Connected Car APIs uses the [OAuth 2.0](https://tools.ietf.org/html/rfc6F49) protocol for authentication and
authorization. Any application require a valid [Access Token](https://tools.ietf.org/html/rfc6749#section-1.4) to access to data.
## Filtering Scopes
- When API caller requests a set of scopes. The owner may not grant access to all of the requested scopes, so the application will have to adapt to the restricted access or request for a larger set of scopes again.
- API backend will deliver the data related to the granted scopes only.
- If no scope has been granted with the caller token then an unauthorized error will be returned.
_If for example the API caller requests for "telemetry" or "trip" endpoint without having the "location" scope, then the resource data returned will not have the vehicle's position but only other data that will satisfy the scopes present in the token._
## Use of Scopes
- Scopes are specified in each individual API.
- Depending on the API, scope can be :
- Mandatory (designed with comment "#Required"): if this scope is not used during the request an error will be returned. An API can have multiple mandatory scopes.
- Optional scopes will return an optional part of the API.
## Hierarchical Scopes
Since API resources are hierarchical, API uses also hierarchical scopes.
_Colon characters_ are used to navigate to subresource scopes.
**The scopes used to request access to resources for the OAuth2 security scheme fall into four categories:**
#### _1. <u>IoT data scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|data:vehicle| read Vehicle attributes data|
|data:telemetry| read full telemetry data|
|data:telemetry:environment|read telemetry environment data|
|data:telemetry:privacy|read telemetry privacy data|
|data:telemetry:vehicle|read full telemetry vehicle data|
|data:telemetry:vehicle:ignition|read telemetry vehicle ignition data|
|data:telemetry:vehicle:location |read vehicle location data|
|data:telemetry:vehicle:preconditioning|read telemetry vehicle preconditioning system data|
|data:telemetry:vehicle:tyreState|read telemetry vehicle tyre data|
|data:telemetry:vehicle:energies|read telemetry vehicle energies data|
|data:telemetry:vehicle:engines|read telemetry vehicle all engines data|
|data:telemetry:vehicle:doorsState|read telemetry vehicle doors state data|
|data:telemetry:vehicle:battery|read telemetry vehicle status battery data|
|data:telemetry:vehicle:safety|read telemetry vehicle safety data|
|data:telemetry:vehicle:odometer|read telemetry vehicle odometer data|
|data:telemetry:vehicle:kinetic|read telemetry vehicle kinetic data|
|data:telemetry:vehicle:propulsion|read telemetry vehicle propulsion mode|
|data:telemetry:vehicle:braking|read telemetry vehicle braking system data|
|data:telemetry:vehicle:wipingBlades|read telemetry vehicle wiping blades data|
|data:telemetry:vehicle:transmission|read telemetry vehicle transmission data|
|data:telemetry:vehicle:adas|read telemetry vehicle ADAS data|
|data:telemetry:vehicle:lightingSystem|read telemetry vehicle lighting system data|
|data:telemetry:vehicle:maintenance |read telemetry vehicle maintenance data|
|data:telemetry:vehicle:drivingBehavior|read telemetry driver behavior data|
|data:telemetry:vehicle:alert|read telemetry alert data|
|data:telemetry:vehicle:alarm|read telemetry alarm data|
|data:trip| read trip related data|
|data:collision| read collision related data|
#### _2. <u>Notification channel scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|channel| read calback related data|
|channel:<b>write</b>| create, modify or delete channels|
#### _3. <u>Vehicle grouping scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|grouping| read groups related data|
|grouping:<b>write</b>| create, modify or delete groups|
#### _4. <u>Vehicle monitor scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|monitor| read monitors|
|monitor:<b>write</b>| create, modify or delete Monitors|
#### _5. <u>Datastream scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|datastream| read exisiting datastream (subscribed, status...) setting|
|datastream:<b>write</b>| create, modify or delete datastreams|
#### _6. <u>Vehicle remotes scopes:</u>_
|<b>Scope</b> |<b>Description</b> |
|---|---|
|remote| read full remote state(pending & history)|
|remote:locking| read door remote (pending & history)|
|remote:locking:<b>write</b>| send a door remote to vehicle|
|remote:horn| read horn remote (pending & history)|
|remote:horn:<b>write</b>| send a horn remote to vehicle|
|remote:lights| read lights remote (pending & history)|
|remote:lights:<b>write</b>| send remote to switch on/off vehicle lights|
|remote:preconditioning| read preconditioning remote (pending & history)|
|remote:preconditioning:<b>write</b>| send a preconditioning remote to vehicle|
|remote:onboardPersonalData| read onboardPersonalData remote (pending & history)|
|remote:onboardPersonalData:<b>write</b>| send an onboardPersonalData remote to vehicle|
|remote:charging| read charging remote (pending & history)|
|remote:charging:<b>write</b>| send charging remote to vehicle|
|remote:wakeUp| read wakeUp remote (pending & history)|
|remote:wakeUp:<b>write</b>| send wakeUp remote to vehicle|
|remote:navigation:write|send desitnation to vehicle|
|remote:vehicleFinder:write|Send find vehicle command |
| remote:navigation|Read send destination to vehicle (pending & history)|
| remote:vehicleFinder|Read vehicle finder command (pending & history)|
---
# API Navigability:
These APIs use [HATEOAS]([https://en.wikipedia.org/wiki/HATEOAS#Implementations) as standard convention for defining resources discovery and navifability (thanks to related hyperlinks).
Adopting HAL simplifies the use of open source libraries and make it possible to interact with the API using JSON.
---
# API Paging:
To make this necessary feature easy to use when retrieving a collection of results, this API uses a token (computed and interpreted by the backend only) as a context that contains all necessary information allowing the navigation through pages.
Token acts as an ```HTTP COOKIE``` on the client-side, so the server does not keep any cache or session settings to continue paging and keep all request stateless. These tokens are used to build HAL (Hypertext Application Language) hyperlinks also.
---
# API Errors:
Error codes returned by all APIs comply with the standard. Nevertheless, PSA Services (callers) need to have more detailed data structures (even when the answer is not Http-OK) to better categorize the type of error by providing application code, message and debugging code(for investigation purposes). The HTTP code of the response is managed by the protocol itself (in the header).
### These APIS are likely to report the following HTTP code:
|<b>Code</b> |<b>Description</b> | <b>Case</b> |
|---|---|---|
|200 |<i>The request has succeeded and the resource data has been sent.</i>|GET APIs. |
|202 |<i>The request has been accepted for processing, but not yet acted upon. An id of processing is returned.</i>|POST/PUT requests:<br>-Create monitor<br>-Create a callbak.|
|204 |<i>The request has been accepted and there is no additional content</i>|DELTE APIs:<br>-Delete monitor.<br>-Delete a channel.|
|400|<i>Request cannot be processed due to invalid query parameter value of body content (for POST/PUT verbs)</i>|ALL APIs.|
|401|<i>Unauthorized request due to lack of valid authentication credentials.</i>|All APIs.|
|403|<i>Unauthorized request due to insufficient credentials to grant access.</i>|All APIs.|
|404|<i>Target resource not found.|All APIs. Even POST, PUT or DELETE if the resource id is uncknown.</i>|
|500|<i>Unexpected condition that prevented from fulfilling the reques.</i>|All APIs.|
|501|<i>Feature not supported</i>|All APIs.|
**Errors are returned as a generic error response:**
* See ```ErrorCodeDefaultResponse``` model.
---
# API output:
## Data format
**All APIs return data in JSON format. The application who uses them must take into account the evolving character of them and more precisely regarding the schemas of the exposed data. Indeed:**
* The missing of known data fields should not cause an error.
* It should (correctly) deal with JSON content with unknown properties also. Indeed, data schema extensions should be supported without errors even if they are not used.
**for example:**
Assuming a given exposed resource with this data schema:
data:
type: object
description: Data model
properties:
field1:
type: string
field2:
type: number
The application should be able to deal with those possible valid JSON contents:
> All fields:
```{
"field1":"value1",
"field2": 1
}```
> Missing field2:
```{
"field1":"value1"
}```
> Unknow field3:
```{
"field1":"value1",
"field3": 2.5
}```
---
license:
name: Stellantis Licence
url: https://www.psa-peugeot-citroen.com/
tags:
- name: Vehicles
description: Access to attributes and IoT data associated with the vehicle.
- name: Trips
description: Describe Trips of a vehicle.
- name: Channels
description: Describe a subscription to an output channel for remote or monitor notification events or data-stream features.
- name: Monitors
description: Describe the vehicle monitor features.
# --- truncated at 32 KB (318 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/stellantis/refs/heads/main/openapi/_original/stellantis-data-treatment-openapi.yml