Intro
Utilization of APIs is extensively used to automate processed and smoothen workflows.
This article will focus on an important aspect when trying to correlate data between Charge Assist (CA) API and Platform API.
For the location object, the ID used in CA domain is different from the ID used in Platform API, as follows:
Platform API - Location ID structure
This API contains all end-points/webhooks related with CPO Data APIs, Charge Location Management API, Remote Commands, EMSP APIs and Smart Charging. More details can be found in the Development Portal.
In all related end-points, the location ID structure is as follows:
You can check this ID easily in EvPortal, by checking in the location object, the field GUID (all chargers in GreenFlux back-end are automatically assigned a GUID as location ID once they are created)
Examples:
avr-90002
d861839a-6663-45c2-8eef-7375027c831a
Notes:
- First example is from an external back-end. Structure is defined as per their business logic.
- The second example is from a charger that is hosted in GreenFlux back-end, whose OCPI id is a GUID, automatically generated by the platform when a location is created.
As follows, an extract of a GET CDR payload:
"location" {
"id": "pt-mob-avr-90002",
"type": "UNKNOWN",
"name": "null".
}Charge Assist API - Location ID structure
This API contains all end-points/webhooks related with Charge Assist API, as defined in more detail here: Intro to Charge Assist (greenflux.com)
In all related end-points, the location ID structure is as follows:
Examples (same locations as illustrated above):
pt-mob-avr-90002
nl-gfx-d861839a-6663-45c2-8eef-7375027c831a
Please pay attention that the OCPI ID used in the construction of the CA API is lowercased.
And as follows an example from GET Locations Bounding Box v2 payload:
{
"id": "pt-mob-avr-90002",
"type": "ON_STREET",
"name": "AVR-90002".
}