Stellantis Capabilities API

openapi: 3.0.0
servers:
  - url: 'https://api-cert.groupe-psa.com/connectedcar/v3'
security:
  - BasicAuth: []
    ClientId: []
info:
  version: '3.19.2'
  title: Groupe PSA Connected Car B2B API
  description: |
    *Business Partner Connected Fleet API*  
    
 
    # Introduction

    This is the description of the *Groupe PSA Connected Car V3 B2B API*. 
    This specification is written in **OpenAPI Specification version 3** and can
    be displayed using [ReDoc](https://github.com/Rebilly/ReDoc) or
    [Swagger](http://swagger.io).
      This REST API allows  applications to fetch data from the connected Vehicles data  platform.
    
    ---
    
    # Authentication

    PSA Connected Car B2B APIs uses the [HTTPS Authentication](https://tools.ietf.org/html/rfc7235) (with provided PSA SSL Certificate) to access to fleet vehicles data.
    
    
    ---
    
    # 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 server 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.
          
    ---
        
    # 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 Remote callback.| 
    | 204  |<i>The request has been accepted and there is no additional content</i>|DELTE APIs:<br>-Delete monitor.<br>-Delete remote callback.|
    |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 unknown.</i>|
    |500|<i>Unexpected condition that prevented from fulfilling the request.</i>|All APIs.|


      
      **Errors are  returned as a generic error response:**
       * See ```ErrorCodeDefaultResponse``` model.
       
    ---
    
       
    # API output:
      ## Data profile
       B2B partners need to return vehicle data with an end-user profile. To do this, the data APIs allow to use an end-user profile according to a query parameter named ```profile```.  Remote,  Monitor, Fleets and Vehicles getter APIs are not affected by this parameter.
     
      ## 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: Groupe PSA Licence
    url: 'https://www.psa-peugeot-citroen.com/'
tags:
  - name: Capabilities
    description: Access to Vehicles details & onboard capabilities
  - name: Fleet
    description: To retreive Fleet details and access resources in **batch mode** (without vehicle or trip filtering).
  - name: Vehicles
    description: Access to Vehicles details.
  - name: Trips
    description: Describe Trips of a Fleet or Vehicle
  - name: Monitors
    description: Vehicles monitors.


# --- truncated at 32 KB (197 KB total) ---
# Full source: https://artifacts.apis.io/stellantis/openapi/stellantis-connected-car-b2b-api-openapi.yml