General information API use

OpenAPI / OAS file

Please view the OAS file via the Link below. Use e.g. https://editor.swagger.io/ to display.

GreenFlux service: https://developer.greenflux.com/openapi/611a6dbd9fc454001c59a066
Charge Location management API: https://developer.greenflux.com/openapi/633acf38357377005460a534

Required, Optional and Nullable fields

This API viewer does not properly display 'nullable' fields.

In general, and according to OCPI documentation, any non-required field in the response or push message can either be

  • null,
  • empty array []
  • the field might be omitted

GreenFlux currently displays arrays without data as an empty array and single fields without data as null. However, some other fields might be omitted completely.
example:
"facilities": [],
"time_zone": null,

API Change Management

RSS subscription

All major updates to API should be published in the ChangeLog.
You can subscribe to any API changes posted in the ChangeLog via RSS using this link: https://developer.greenflux.com/changelog.rss

here is a link how to use RSS for Outlook:

change management process

GreenFlux is in the process of outlining a Change Management Process. Below is an early indication of what we as Product & Development strive towards. No rights or responsibilities should currently be drawn from the below.

API change management process
For modifying an API, the following should be adhered to:

  • Do not take anything away
  • Do not change processing or business rules
  • Do not make optional things required
  • Anything added MUST be optional

If the above is followed, it should be backwards compatible and changes be released without major announcement.
Anything that does not conform to the above must be considered a Breaking Change.

Announcements on non-breaking changes should be made at least 2 weeks in advance.

🚧

Adding optional fields

GreenFlux does not consider adding optional fields to an API as a Breaking Change.

Breaking change
A breaking change is a change to an API that could potentially cause failures in the applications that consume that API. If a change could cause API calls to fail or cause API calls to return different results than before the change, then we consider it a breaking change.

Breaking Change can be classified according to impact or severity:

  • Minor: e.g. removal of a field that nobody is using
  • Medium: e.g. change to publishing rules of a location or new mandatory query parameter
  • Major: e.g. New version or resource metadata

Suggested timelines for announcing breaking changes:

  • Minor: 1 month (outside of major holiday seasons)
  • Medium: 3 months
  • Major: 6 months (subject to impact)