UNLOCK_CONNECTOR: releasing a latched cable

Why cables latch in the first place

The lock is a safety feature, not a defect. During a session the connector is mechanically latched so it cannot be pulled out under load — disconnecting a DC connector mid-charge would arc. On AC, Type 2 cables lock at both ends so a cable cannot be stolen from a charging vehicle.

Normally the latch releases automatically when the session ends. It fails to when:

• The session did not close cleanly — the charger still believes power may be flowing.
• The vehicle holds its side locked, which is a car-side setting the charger cannot override.
• The latch is mechanically jammed, frozen, or obstructed.
• The charger lost connectivity mid-session and never processed the stop.

The fields

Note that this command addresses physical hardware, not a session. That is deliberate: the situation it exists for is precisely one where the session has already ended or gone wrong, so a session ID would be useless.

Worked example

POST /ocpi/2.2.1/commands/UNLOCK_CONNECTOR
Authorization: Token <base64 token>
OCPI-from-country-code: IN
OCPI-from-party-id: EMS
OCPI-to-country-code: IN
OCPI-to-party-id: EFI
X-Request-ID: 9d02b613

{
  "response_url": "https://emsp.example.com/ocpi/2.2.1/commands/UNLOCK_CONNECTOR/9d02b613",
  "location_id": "LOC-ND-014",
  "evse_uid": "EVSE-014-02",
  "connector_id": "1"
}

Where the CPO supports it:

HTTP/1.1 200 OK
{ "data": { "result": "ACCEPTED", "timeout": 30 }, "status_code": 1000,
  "timestamp": "2026-08-11T23:07:41Z" }

POST /ocpi/2.2.1/commands/UNLOCK_CONNECTOR/9d02b613
{ "result": "ACCEPTED" }

And the response you should expect to handle just as often:

HTTP/1.1 200 OK

{
  "data": { "result": "NOT_SUPPORTED" },
  "status_code": 1000,
  "timestamp": "2026-08-11T23:07:41Z"
}

Why CPOs disable it

The reasoning is worth understanding rather than treating as obstruction:

• Safety. Unlocking while current flows risks arcing. A CPO that cannot be certain of session state from a remote command may refuse rather than take the risk.
• Liability. If a remote unlock triggered by a third party contributes to damage or injury, the CPO owns the incident even though it did not initiate the command.
• Theft. A remote unlock on an unattended vehicle can release an expensive cable. Some networks have seen this abused.
• Hardware variance. Not every charger model implements UnlockConnector reliably. A CPO with mixed estate may disable it rather than support it inconsistently.

The practical consequence: treat NOT_SUPPORTED as the expected answer on a meaningful share of your partner networks, cache it per partner, and stop offering the action where it will never work.

Designing the driver flow

Because the command is unreliable by nature, the product design around it matters more than the integration. A flow that holds up:

1. Check the obvious first. Prompt the driver to unlock the car and try the release from inside the vehicle. This resolves a large share of cases with no command at all.
2. Confirm the session has ended. If it has not, stopping it is the correct first action — the latch will usually release on its own.
3. Try the unlock, if the partner supports it.
4. Escalate to a human immediately on failure. Show the CPO's support number. A stranded driver needs a phone number, not a retry button.

Never present this as a one-tap fix. The honest framing — “we will try to release it remotely; if that does not work, here is who to call” — produces far better outcomes than a button that silently fails.

Production lessons

• Stop the session before attempting unlock. An active session is the most common reason the latch is held, and stopping it often removes the need for this command entirely.
• Cache NOT_SUPPORTED per partner and hide the action. Offering a button that always fails is worse than not offering it.
• Always surface CPO support contact alongside it. This is the one command where the fallback matters more than the command.
• Log every attempt with location, EVSE and outcome. Clusters of unlock attempts at one site point to a hardware fault the CPO needs to hear about — this is genuinely useful partner feedback.
• Never auto-retry in a loop. Repeatedly commanding a latch is pointless and, on some hardware, harmful.
• Set expectations in the copy. “Trying to release — this does not work on every charger” is honest and reduces complaints.