Skip to main content
Charge versions the API so it can introduce breaking changes without forcing every integration to change at the same time. Most integrations do not need to set a version explicitly. If you do nothing, Charge uses your account’s default API version, which is the normal starting point for a new integration. When you need to override it for a request, send the Charge-Version header.
cURL
curl https://api.chargeapi.co/v1/charging_sessions \
  -H "Authorization: Bearer ch_sk_test_..." \
  -H "Charge-Version: 2026-03-01"
In practice, versioning matters when a change would otherwise affect how your integration reads responses or sends data. That can include payload shape, field behavior, or validation rules. Versioning matters most for webhook delivery. If one consumer needs to stay on a fixed payload shape during an upgrade, set api_version on that Webhook Endpoint. If you leave it unset, the endpoint uses the account default version. Each Event stores the api_version that was used to render its payload when the event was created. Treat events as snapshots: changing your account default later does not rewrite older event payloads. When you upgrade, test the target version first and move webhook consumers deliberately. In most cases, the right approach is to keep using the account default and pin a version only when you need controlled rollout for a specific endpoint.