Backwards compatibility

Infobip evolves its APIs over time while maintaining backward compatibility. Understanding what that commitment covers helps you build integrations that stay stable across updates.

What Infobip commits to

Within the same MAJOR version, Infobip will:

• Only add new fields to request models as optional — existing requests without those fields will continue to work.
• Never remove, rename, or change the type of an existing response field.
• Never change the meaning of an existing status code or error response.
• Provide advance notice before deprecating any endpoint, with a migration path to the replacement.

What your integration should handle

Even within a backward-compatible API, certain implementation patterns can cause breakage when the API evolves. The following covers the most common cases.

New fields in responses

Infobip may add new fields to response models at any time. Your parsing implementation should ignore fields it does not recognise, rather than treating them as errors. This way you benefit from new response data without needing to update your code for every release.

New enum values

Infobip may add new values to existing enum fields in responses as part of a MINOR update. If your code uses a strict switch/case that only handles known values and throws on anything unrecognised, a new enum value becomes a breaking change on your end even though it is not one on Infobip's end.

Handle unknown enum values explicitly with a default or fallback case, and log or ignore them rather than failing hard.

JSON property order

The JSON specification does not guarantee the order of properties in an object. Do not write parsing logic that depends on a specific property appearing in a specific position. Using your language's standard JSON library handles this correctly by default.

Date formats

Dates are returned in the following format by default:

The format includes timezone information. The two strings below represent the same moment in time and should be treated identically:

Do not assume responses will always carry a specific timezone offset. Convert date strings to your language's native datetime type on receipt and let that type handle timezone normalization.

Deprecation and sunset

When an endpoint is deprecated, you will receive advance notice through the OpenAPI specification, response headers, documentation, and direct email if you are actively using the affected endpoint. Deprecated endpoints remain operational during a grace period before being permanently shut down.

For full details on the deprecation process, timeline, and what to expect before shutdown, see Deprecation.