Skip to content

Versioning

The InPost REST APIs are versioned.

Specifying an API version in a path

In comparison with Legacy APIs versioning approach was updated. The API path was redesigned to enable per-product versioning, as in below examples:

  • api.inpost-group.com/account/v1/
  • api.inpost-group.com/location/v1/
  • api.inpost-group.com/shipping/v2/
  • api.inpost-group.com/pickups/v1/
  • api.inpost-group.com/returns/v1/
  • api.inpost-group.com/tracking/v1/

Moreover date versioning (i.e. 2024-06-01) was replaced by a number (i.e. v1).

Examples

curl -X GET https://api.inpost-group.com/location/v1/points
curl -X POST https://api.inpost-group.com/shipping/v2/organizations/{organizationId}/shipments

Any breaking changes will be released in a new API version. Breaking changes are changes that can potentially break an integration. Breaking changes include:

  • removing an entire operation
  • removing or renaming a parameter
  • removing or renaming a response field
  • adding a new required parameter
  • making a previously optional parameter required
  • changing the type of a parameter or response field
  • removing enum values
  • adding a new validation rule to an existing parameter
  • changing authentication or authorization requirements

Any additive (non-breaking) changes will be available in all supported API versions. Additive changes are changes that should not break an integration. Additive changes include:

  • adding an operation
  • adding an optional parameter
  • adding an optional request header
  • adding a response field
  • adding a response header
  • adding enum values

When a new REST API version is released, the previous API version will be supported for at least 12 months following the release of the new API version.