Before you start
This playbook is for fleet management and telematics platforms integrating with Spirii. You’ll need an API key — created by an operator in Connect, it grants access to every endpoint you’ll use here — and a working understanding of tokens, which are how drivers and vehicles authenticate to charge.How the pieces fit
Two objects carry a fleet integration, and it helps to hold them in mind before you start:- A customer is an account you bill — a sub-fleet, department, or cost centre.
- A token is how a driver (an app or RFID) or a vehicle (Autocharge) authenticates to charge. Registering a token grants it access to charge; each token is linked to the customer that should be billed.
Set up the fleet
1
Model sub-fleets as customers
Create a customer for each account you bill separately. Set its See Create a customer for the billing and financial fields to include if you use Spirii’s financial services.
type (usually Business), the parent account via ownerId, and an externalId that maps it to the account in your own system.2
Register drivers' and vehicles' tokens
A fleet usually already has the means to charge — RFID charge cards, or fuel cards with an RFID chip that can be repurposed for charging. Creating a token in the platform registers that credential so Spirii recognises it and authenticates charging against it. You’ll typically:See Create a token and the Tokens component for the three token types and their fields.
- register RFID tokens the fleet already holds, by their chip UID,
- create virtual tokens for drivers authenticating through an app,
- register vehicle (Autocharge) tokens by a vehicle’s MAC address or VIN.
customerId.Verify
Have a provisioned token start a charge at the depot. The session appears in Transactions, and once it ends a CDR is generated carrying that token and its customer — confirming both access and billing attribution are set up correctly.
Track charging
Once the fleet is charging, the API gives you both a live view and a settled record. The generic retrieval mechanics — paging, incremental sync, and the rate and record limits — are covered in the Reporting and dashboards playbook; below is what matters for a fleet, starting with the live view, which is where this integration earns its keep.Live sessions and state of charge
The live session feed is the most valuable one for a fleet. Transactions lists sessions in progress and recently finished, so you can see which vehicles are charging right now, how much they’ve drawn so far, and, on DC chargers, the vehicle’s reported state of charge, which tells you when it will be ready to leave. Filter to a token to follow a single driver or vehicle in real time. Feed this into dispatch, route planning, and live operations dashboards: a vehicle’s charge level and expected ready time are exactly what a fleet system needs to plan the next leg.Depot status
Poll Locations for depot capacity and live EVSE and connector status — which bays are free, which are faulted — to plan charging windows and routing. See the Locations component.Completed sessions
Each finished session becomes a CDR carrying the token and customer, so you can attribute cost and consumption to a driver, vehicle, or sub-fleet. Filter by the token or customer, then use the Reporting and dashboards playbook to turn CDRs into reports. See the Sessions and CDRs component.Best practices
- Map your own IDs. Set
externalIdon customers and a recognisablelabelon tokens, and join onlocation.idandevseIdwhen reconciling with your system. See Identifiers. - Sync incrementally and page fully. Pull only what changed and follow the cursor to the end, so a scheduled sync moves the new records rather than re-pulling the whole history each run. See Filtering and Pagination.
- Retry transient errors safely, and don’t retry a rejected request unchanged. See Errors.
Next steps
Reporting and dashboards
The retrieval patterns for turning charging data into reports.
Pylon
Set up the Pylon integration.