Definition
Platform Integration refers to the interconnection of data and business between IoT platforms and third-party systems (such as charging platforms, logistics platforms, ERP, CRM) through APIs, standard protocols, or middleware. Platform integration is a key means to achieve interoperability, enabling cross-system collaboration for device management, billing, operations, and maintenance. In scenarios such as cross-border charging roaming, cross-border logistics, and multi-platform aggregation, platform integration supports the integration of standard protocols like OCPI, OCPP, as well as custom APIs.
Technical Features and Architecture
Technical features of platform integration include: Standardized Protocols—such as OCPI, OCPP used for charging; RESTful API—for synchronizing data such as device status, CDR, and users; Message Queues—for asynchronous event pushing and data synchronization; Loose Coupling—reducing inter-system dependencies through loose coupling design. Typical architecture includes: API gateway, protocol adaptation layer, data synchronization and mapping, security authentication (OAuth, API Key). Cross-border scenarios need to consider multiple time zones, multiple currencies, multiple languages, and regional data compliance (such as data localization).
Application in IoT and cross-border scenarios
Platform integration applications in IoT and cross-border scenarios include: Charging Roaming——Charging Platform integrates with eMSPs and aggregators via OCPI to achieve cross-border charging and settlement; Device Management——Device Management Platform integrates with customer business systems for device, traffic, and alarm management; Logistics——Logistics Platform integrates with warehousing, transportation, and customs systems; Operations——Operations Platform integrates with work order and customer service systems. SimtoLink supports flexible integration with customer platforms, helping realize cross-border IoT business.
Fields, Events, and Idempotency in Platform Integration
Platform integration is two systems reaching an exchange of the same business object that both can check. The object may be a card, a device, a charging session, a meter reading, or a ticket. The exchange may be request and response, or an event notification. Either way, both sides need a field table that names its version: name, type, unit, time zone, whether it may be empty, and the enumeration values. Without a version number, one side adds a status value and the other still drops it under the old enumeration, which looks as if the data was never reported. A cross-border interface also has to say which currency's minor unit the amount uses, whether energy is in watt-hours or kilowatt-hours, and whether time is a full moment with an offset or a local string with no time zone.
An event carries a change that has already happened, such as a session closing, a state change, or a boundary crossing. The receiver must recognize a duplicate delivery. The idempotency key should come from a business identifier, such as the session number plus the close count, not from a new random number on every retry. A random number turns one close into two bills. If pull and push are both on, deduplicate with the same idempotency key, or the night reconciliation will see the energy twice. A failure response must distinguish temporarily unavailable, which may be retried, from an illegal field, which will fail again. Retrying the second kind only blocks the queue.
What Must Be True Before a Joint Test Moves to Production
A move to production is appropriate when the sandbox has used the same version and enumerations as production, clock skew is inside the agreed range, authentication credentials are split by environment, rate limits and timeouts are written into both sides' expectations, and both sides have agreed how one failure sample is handled. Checking only the success path is not enough. At least one duplicate delivery, one missing field, and one late catch-up upload should be walked through. A catch-up upload must land in the original billing period, not on the day it was uploaded. If the visited platform and the home platform belong to different parties, also confirm who may correct a record that has already been received, and how a correction message cites the original record.
Accounts That Go Wrong Because the Same Name Means Two Things
A common mistake is that both sides have an energy or amount field, one in watt-hours and one in kilowatt-hours, and the money is off by a thousand times before anyone notices. Another is that the end time is the time the server received the message. The session arrives late on a cross-border link, and the duration is counted short or falls into the next hour's tariff. A third is that error codes are not classified, a brief network break triggers retries without limit, and the same detail record is written as several bills. A fourth is that only a query interface is connected, with no events, so the platform believes the status is live when it is actually waiting for the next pull. Enumeration values that use display text instead of a stable code fail to parse as soon as the language changes. The go-live list should fix units, the idempotency key, the meaning of time, and the error classes, and compare one known reading end to end, rather than only looking at a successful interface response.
During the first week after go-live, compare one known reading end to end every day. The comparison covers energy or usage, the minor currency unit, the time zones of start and end, and whether the idempotency key produced only one bill. If the comparison fails, stop writing production accounts and keep the original message. Store sandbox credentials apart from production credentials, so a joint-test script does not replay into production. When the other side adds an enumeration value, an unknown value should enter a quarantine queue and raise an alert. Do not drop it silently, or a new status will look as if the device stopped reporting. After the field table is updated, replay the quarantined messages with the original idempotency key. Take the known reading from a frozen value on the meter or the charger. The receiver must not invent it.
Keep the original message and the source of the frozen value with the comparison record, so a unit-conversion error can be told apart from a time-zone error. Resume ordinary batch writes only after the comparison has matched for several days in a row. Unknown enumerations stay in the quarantine queue and do not enter a formal bill.