Versioning

Your API version controls the API and webhook behavior you see (for example, what properties you see in responses, what parameters you’re permitted to send in requests, etc.). When we change the API in a backwards-incompatible way, we release a new dated version.

Generally you will want to pass a version header with every request. Requests with no version header are defaulted to the most recent version, which can contain backwards-incompatible changes that your application cannot handle.

Backwards compatibility

Podium considers the following changes to be backwards compatible:

• Adding new API resources.
• Adding new optional request parameters to existing API methods.
• Adding new properties to existing API responses.
• Changing the order of properties in existing API responses.
• Changing the length or format of opaque strings, such as object IDs, error messages, and other human-readable strings.
• This includes adding or removing fixed prefixes (such as ch_ on charge IDs).
• You can safely assume object IDs we generate will never exceed 255 characters, but you should be able to handle IDs of up to that length. If, for example, you’re using MySQL, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column (the COLLATE configuration ensures case-sensitivity in lookups).
• Adding new event types.

Your webhook listener should gracefully handle unfamiliar event types.