Fleet Software Integrations: Planning APIs for Electric Fleets

Integrations connect fleet software to other operational data sources and applications. An API provides a defined technical interface through which systems can read or change specific information. For your electric fleet, what matters is which data is actually available, how reliably it is transferred and who handles errors during ongoing operations.

“API available” is not a sufficient requirement. An interface might provide vehicle master data without supplying state-of-charge or billing data, for example. First describe the workflow you want, then the fields, permissions and updates it requires.

Map the data flow before technical implementation

For each use case, record the source, destination and direction of transfer. Do you want to import vehicle master data into the fleet software? Should confirmed charging sessions feed into an analysis? Or should a changed status become visible in another working area?

For every field, it must be clear which system holds the authoritative information. If two systems may change the same cost centre, you need a conflict rule. Without it, a technically successful transfer can produce incorrect business data.

Start with a manageable data flow. Define the expected benefit, such as avoiding repeated manual entry. The article on vehicle master data in fleet software explains the foundations of suitable vehicle identifiers.

Agree content and freshness together

An interface description should name the available objects and fields. You also need the meaning of timestamps, units, statuses and empty values. Clarify whether all vehicles are supported and whether data is available only for certain periods.

The main questions for the business design are:

• Which fields are actually supplied?

• Which unique identifiers link vehicles and sessions?

• How quickly does new or changed data become available?

• Are changes transmitted, or only complete current datasets?

• How are deleted or deactivated entries identified?

• How far back can historical data be retrieved?

• Which volume or request limits need to be considered?

Choose the update schedule to suit the purpose. A monthly report needs a complete closing dataset. A short-notice dispatch decision may need a much tighter time window. Frequent requests do not make an infrequently updated source more current.

Plan for interruptions and retries

A connection can be interrupted after a record has already been processed. The integration therefore needs to recognise whether a retransmission refers to the same record. Stable identifiers and documented retry rules are important for this.

For HTTP methods, the technical term “idempotent” describes multiple identical requests having the same intended effect on the server as a single request. RFC 9110 sets out the rules. This property needs to be checked for the specific transfer step; it does not follow simply from the word API. Source: HTTP rules for repeatable requests.

Also define how failed records will be processed again. The operations team needs a clear error list with an identifier, timestamp, cause and next step. A technical error message without the associated business record is difficult for a fleet team to act on.

Practical example: A charging import after a connection failure

Illustrative integration example: A regular retrieval transfers 80 confirmed charging sessions. The connection fails after the 50th session. On the next attempt, the source supplies the same dataset again.

The integration needs to recognise the sessions already imported and add the remaining ones. The destination then contains exactly the 80 expected sessions. Processing records which identifiers were already present and which were newly imported.

In the next test, an existing session is corrected in business terms. It must now also be clear whether the current version is replaced, supplemented or recorded as a correction. A process that only prevents duplicates does not yet address this second task. Both cases belong in acceptance testing.

Checklist: Seven questions for integration acceptance

Ask to see the planned workflow using anonymised sample data. Check typical disruptions as well as successful transfers.

1. Do all agreed fields arrive with understandable meanings?

2. Is all missing data supplied after an interruption?

3. Does a repeated run avoid unwanted duplicates?

4. Are corrections and deactivated entries handled correctly?

5. Are missing and outdated data visible?

6. Is technical access limited to the scope required?

7. Are named people responsible for operations and changes?

Record the result in an acceptance report. A new interface version or a changed field meaning can affect the data flow. Agree how changes will be announced, tested and approved.

Support reliable ongoing operation

For ongoing operations, you need a visible timestamp for the last successful run, information on outstanding records and a responsible contact. Decide which outages require immediate attention and which can wait until the next working day.

Technical accounts need permissions that are just as clear as those of human users. Guidance on dividing them is provided in fleet management roles and permissions. For a file-based handoff, the guide to fleet software data exports adds further checks.

With StromNow for fleets, you can discuss your charging organisation and billing requirements. Bring the desired data flow and clarify which connections are available for your specific use case.