OCPP 1.6 vs 2.0.1 is a charger and management-system question before it is a voice support question. Open Charge Point Protocol carries messages between those systems. EVCalls connects to the CPMS through its API or webhooks, rather than acting as the charger-facing protocol endpoint.
A version label is not an integration test
The Open Charge Alliance documents both SOAP and JSON support in OCPP 1.6. Describing it as SOAP-only is incorrect. Its OCPP 2.0.1 documentation describes added device-management and security capabilities and notes that 2.0.1 is not backward compatible with 1.6.
That still doesn't establish what a particular CPMS exposes to an external support service. Your installation, access permissions, available fields, and supported requests need their own review.
Ask for the information the call needs
For each call reason, identify the station and connector fields, available status, and the meaning of each response. Check whether the response describes the request being accepted or the requested outcome actually occurring. Delayed or missing information needs a defined caller explanation.
We test these details through the CPMS interface with your technical team. A mixed charging fleet needs representative tests across the equipment and configurations included in the pilot, not a universal compatibility promise based on protocol names.
Keep changes connected to support instructions
When the CPMS or charger configuration changes, review any affected instructions and requests. A previously valid test does not answer every future configuration question. Keeping those tests attached to the call workflow helps your support and technical teams review the same evidence.
Sources reviewed September 6, 2026
We can use these decisions to scope CPMS integration review around your network, systems, and receiving team.