{
  "aid": "groupe-psa.io:main-3.19.2",
  "name": "Groupe PSA Connected Car B2B API",
  "type": "Index",
  "description": "*Business Partner Connected Fleet API*  \n\n\n# Introduction\n\nThis is the description of the *Groupe PSA Connected Car V3 B2B API*. \nThis specification is written in **OpenAPI Specification version 3** and can\nbe displayed using [ReDoc](https://github.com/Rebilly/ReDoc) or\n[Swagger](http://swagger.io).\n  This REST API allows  applications to fetch data from the connected Vehicles data  platform.\n\n---\n\n# Authentication\n\nPSA 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.\n\n\n---\n\n# Paging:\n  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. \n  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.\n      \n---\n    \n# Errors:\n  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).\n    \n### These APIS are likely to report the following HTTP code:\n\n| <b>Code</b>  | <b>Description</b>  |  <b>Case</b> |  \n|---|---|---|\n| 200  |<i>The request has succeeded and the resource data has been sent.</i>|GET APIs.  |\n| 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.| \n| 204  |<i>The request has been accepted and there is no additional content</i>|DELTE APIs:<br>-Delete monitor.<br>-Delete remote callback.|\n|400|<i>Request cannot be processed due to invalid query parameter value of body content (for POST/PUT verbs)</i>|ALL APIs.|\n|401|<i>Unauthorized request due to lack of valid authentication credentials.</i>|All APIs.|\n|403|<i>Unauthorized request due to insufficient credentials to grant access.</i>|All APIs.|\n|404|<i>Target resource not found.|All APIs. Even POST, PUT or DELETE if the resource id is unknown.</i>|\n|500|<i>Unexpected condition that prevented from fulfilling the request.</i>|All APIs.|\n\n\n  \n  **Errors are  returned as a generic error response:**\n   * See ```ErrorCodeDefaultResponse``` model.\n   \n---\n\n   \n# API output:\n  ## Data profile\n   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.\n \n  ## Data format\n  \n  **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:**\n  \n  *  The missing of known data fields should not cause an error. \n  *  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. \n    \n  \n  **for example:**\n  \n  Assuming a given exposed resource with this data schema:\n    \n      \n       data:\n        type: object\n        description: Data model\n        properties:\n          field1:\n            type: string\n          field2:\n            type: number\n         \n  The application should be able to deal with those possible valid JSON contents:\n    \n  > All fields:\n    ```{\n      \"field1\":\"value1\",\n      \"field2\": 1\n    }```\n    \n  > Missing field2:\n    ```{\n      \"field1\":\"value1\"\n    }```        \n\n  > Unknow  field3:\n    ```{\n      \"field1\":\"value1\",\n      \"field3\": 2.5\n    }```\n  \n \n---  \n",
  "url": "https://raw.githubusercontent.com/jentic/jentic-public-apis/refs/heads/main/apis/openapi/groupe-psa.io/main/3.19.2/apis.json",
  "tags": [
    "groupe-psa.io",
    "main"
  ],
  "created": "2026-04-10",
  "modified": "2026-04-10",
  "specificationVersion": "0.19",
  "access": "3rd-Party",
  "maintainers": [
    {
      "FN": "Jentic",
      "X-github": "jentic",
      "url": "https://github.com/jentic"
    }
  ],
  "apis": [
    {
      "aid": "groupe-psa.io:main-3.19.2",
      "name": "Groupe PSA Connected Car B2B API",
      "description": "*Business Partner Connected Fleet API*  \n\n\n# Introduction\n\nThis is the description of the *Groupe PSA Connected Car V3 B2B API*. \nThis specification is written in **OpenAPI Specification version 3** and can\nbe displayed using [ReDoc](https://github.com/Rebilly/ReDoc) or\n[Swagger](http://swagger.io).\n  This REST API allows  applications to fetch data from the connected Vehicles data  platform.\n\n---\n\n# Authentication\n\nPSA 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.\n\n\n---\n\n# Paging:\n  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. \n  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.\n      \n---\n    \n# Errors:\n  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).\n    \n### These APIS are likely to report the following HTTP code:\n\n| <b>Code</b>  | <b>Description</b>  |  <b>Case</b> |  \n|---|---|---|\n| 200  |<i>The request has succeeded and the resource data has been sent.</i>|GET APIs.  |\n| 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.| \n| 204  |<i>The request has been accepted and there is no additional content</i>|DELTE APIs:<br>-Delete monitor.<br>-Delete remote callback.|\n|400|<i>Request cannot be processed due to invalid query parameter value of body content (for POST/PUT verbs)</i>|ALL APIs.|\n|401|<i>Unauthorized request due to lack of valid authentication credentials.</i>|All APIs.|\n|403|<i>Unauthorized request due to insufficient credentials to grant access.</i>|All APIs.|\n|404|<i>Target resource not found.|All APIs. Even POST, PUT or DELETE if the resource id is unknown.</i>|\n|500|<i>Unexpected condition that prevented from fulfilling the request.</i>|All APIs.|\n\n\n  \n  **Errors are  returned as a generic error response:**\n   * See ```ErrorCodeDefaultResponse``` model.\n   \n---\n\n   \n# API output:\n  ## Data profile\n   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.\n \n  ## Data format\n  \n  **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:**\n  \n  *  The missing of known data fields should not cause an error. \n  *  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. \n    \n  \n  **for example:**\n  \n  Assuming a given exposed resource with this data schema:\n    \n      \n       data:\n        type: object\n        description: Data model\n        properties:\n          field1:\n            type: string\n          field2:\n            type: number\n         \n  The application should be able to deal with those possible valid JSON contents:\n    \n  > All fields:\n    ```{\n      \"field1\":\"value1\",\n      \"field2\": 1\n    }```\n    \n  > Missing field2:\n    ```{\n      \"field1\":\"value1\"\n    }```        \n\n  > Unknow  field3:\n    ```{\n      \"field1\":\"value1\",\n      \"field3\": 2.5\n    }```\n  \n \n---  \n",
      "image": "",
      "baseURL": "https://api-cert.groupe-psa.com/connectedcar/v3",
      "humanURL": "https://github.com/jentic/jentic-public-apis/tree/main/apis/openapi/groupe-psa.io/main/3.19.2",
      "version": "3.19.2",
      "tags": [
        "groupe-psa.io",
        "main"
      ],
      "properties": [
        {
          "type": "OpenAPI",
          "name": "OpenAPI definition",
          "url": "https://raw.githubusercontent.com/jentic/jentic-public-apis/refs/heads/main/apis/openapi/groupe-psa.io/main/3.19.2/openapi.json",
          "mediaType": "application/openapi+json"
        },
        {
          "type": "GitHubRepo",
          "url": "https://github.com/jentic/jentic-public-apis/tree/main/apis/openapi/groupe-psa.io/main/3.19.2"
        }
      ]
    }
  ]
}