Projects

A project is one charging operation, run on its own. Chargers, locations, sessions, drivers and cards each belong to exactly one project, and nothing crosses from one project to another. Most organizations run everything in the one project they start with, prod.

When to add a project

Add one when you have a genuinely separate operation:

• A second brand, run from the same account but never mixed with the first.

• A client whose chargers you operate, whose fleet and data should be apart from yours rather than filtered.

• Another country, where the fleet, its people and its reporting are run separately.

Two depots of the same operation are two locations in one project, not two projects. Keeping them together keeps one view across both, one set of drivers and one set of access grants.

Give people access to one project

A member holding the Admin policy at the organization reaches every project. A member holding the User policy at one project reaches only that project, which is how a client's staff or a contractor get their project and nothing else:

curl -X POST \
  "$API/organizations/$ORG/members/$MEMBER/bindings" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"policyId": "'"$USER_POLICY"'", "projectId": "'"$PROJECT"'"}'

API keys work the same way: a key holding Admin at the organization reaches every project, a key holding User at a project reaches exactly that one. See Permissions and policies. Membership belongs to the organization, not to a project, and so does billing: usage is billed to a billing account that the organization attaches to.

Test in sandbox mode

Every project has two modes, live and sandbox, from the moment it is created. Live is your real fleet. Sandbox is a separate space in the same project where you build and test your integration:

• Each API key belongs to one mode. Sandbox keys start with flw_ak_test_.

• In the console, switch between the two at any time.

• Sandbox has virtual chargers instead of hardware, and its own drivers, cards and sessions.

• Nothing done in sandbox mode reaches a live charger or a real invoice.

So there is no need for separate "dev" and "staging" projects: every project already has a place to test.

The default project

One project in the organization is the default. It matters for one thing: a charger whose connection address names no project connects to the default project.

wss://ocpp.flowion.io/acme            → the default project
wss://ocpp.flowion.io/acme/nordics    → the project "nordics"

Change the default with POST /organizations/$ORG/projects/$PROJECT/default. The default project cannot be deleted; make another project the default first.

Names and slugs

A project has a name, for people, and a slug that appears in connection addresses: lowercase letters and digits in hyphen-separated segments, at most 63 characters. A slug is unique within the organization, so two organizations can both have a project called nordics.

Nothing about a project depends on its name. prod is only the name the first project gets; rename it freely.

Renaming never changes the slug. Changing the slug is a separate request that must include "acknowledgeDisconnectsStations": true, because every charger connecting through an address with the old slug needs the new one.

Time zone and price zone

A project can carry a time zone, the IANA name (Europe/Stockholm) your team reads its times in. Times in the API are always unambiguous; this only sets how they are shown.

The price zone, the electricity market your day-ahead prices come from, belongs to each location instead, because a Swedish depot and a German one sit in different markets. A location can also have its own time zone.

Moving a charger to another project

A charger belongs to one project. To move it, create it in the new project and configure the hardware with the new address and authorization key. Its past sessions stay in the project where they happened.

Decide where a charger lives before it is installed, and you will rarely need to.