Rotate tokens periodically or immediately if a credential is compromised.
When to rotate
- Scheduled security policy (e.g. every 90 days)
- Suspected token leak or unauthorized access
- Staff departure with credential access
- Platform migration or URL change
Rotation procedure
1. Generate a new token on your platform
Create a new token (token B) on your side. Keep the current token (token A) active during rotation.
2. Update credentials via PUT
PUT /ocpi/2.2.1/credentials
Authorization: Token {current-hub-token}
Content-Type: application/json
{
"token": "your-new-token-B",
"url": "https://your-platform.com/ocpi/2.2.1",
"roles": [ ... ]
}
The Hub stores token B alongside token A during the transition period.
3. Verify with new token
Test connectivity using token B:
GET /ocpi/2.2.1 Authorization: Token your-new-token-B
4. Revoke old token
Contact your account team to revoke token A after confirming all your systems use token B. Allow a 24-hour overlap window for in-flight requests.
If the Hub rotates the token it uses to call your platform, your account team will notify you. Update your token validation to accept the new Hub token before the old one is revoked.
Best practices
- Rotate during low-traffic windows
- Monitor error rates (
2002) after rotation - Update all services and environments simultaneously
- Never commit tokens to source control