Deprecation
Deprecation is the process Infobip uses to retire an API endpoint. A deprecated endpoint keeps working until its sunset date, which gives you time to migrate your integrations. Some deprecated endpoints have no sunset date.
Terminology
The following terms describe endpoint lifecycle states:
- Superseded: An endpoint for which a later, recommended version exists, but which still works and is still supported. A superseded endpoint is not deprecated: it has no sunset date, and you are not required to migrate. Use the current version for new integrations. See API versioning.
- Deprecated: An endpoint that is obsolete and not recommended for use, but remains operational. It is on a path to retirement and might be discontinued at a scheduled date. Being deprecated is a deliberate decision to retire an endpoint, not an automatic result of a later version being released.
- Deprecation period: The time between the deprecation date and the sunset date, during which you migrate to the successor endpoint. Infobip sets the deprecation period for each endpoint, based on factors such as how widely the endpoint is used and how complex the migration is.
- Sunset: An endpoint that has been permanently shut down and is no longer operational. Calls to a sunset endpoint return HTTP
410 Gone.
How Infobip notifies you
When Infobip deprecates an endpoint, it announces the deprecation in the following places:
- OpenAPI specification: The endpoint is marked with the standard
deprecatedflag. Its deprecation metadata includes the deprecation date, the planned sunset date, and the successor endpoint if available. - API response headers: Calls to deprecated endpoints return a
Deprecationheader and, when a sunset date is configured,SunsetandLinkheaders. See API response headers. - Documentation: Both the deprecated and replacement versions are documented. The deprecated version remains visible until its sunset date.
- Email notifications: If you actively use a deprecated endpoint, you receive an email about the timeline and migration path.
API response headers for a deprecated endpoint
When you call a deprecated endpoint, the response includes headers that indicate the deprecation status and, if configured, the sunset date and related links.
The headers in the response depend on whether the endpoint has a configured sunset date:
- Sunset date configured: The response includes all three headers.
Deprecationcontains the deprecation date,Sunsetcontains the sunset date, andLinkpoints to related resources. - No sunset date configured: The response includes only
Deprecation: trueas a boolean flag.
The following example shows the headers for an endpoint with a configured sunset date:
Link header: The header can include two values. rel="successor-version" points to the documentation for the replacement endpoint, and rel="deprecation" links to more information about the deprecation, such as its policy, timeline, or rationale.
The successor-version link points to the API reference page for the replacement endpoint. Infobip resolves that target from the successor operation ID declared in the OpenAPI metadata of the endpoint, so it always tracks the current recommended version.
What to expect before shutdown
Infobip does not apply a fixed deprecation period. When a deprecated endpoint has a sunset date, the date is published in its OpenAPI deprecation metadata and in the Sunset response header. The email to active users also includes it.
A deprecated endpoint keeps working normally until its sunset date. As the date approaches, Infobip continues to remind active users through the notification channels so an overlooked dependency does not go unnoticed. After the sunset date, the endpoint returns HTTP 410 Gone.
Some deprecated endpoints have no sunset date. Such an endpoint might keep working indefinitely, but it remains deprecated and is not recommended for use.
To move off a deprecated endpoint, migrate to the successor listed in its deprecation metadata before the sunset date. For help planning a migration, contact your account manager or Support.
Backward compatibility
What the backward-compatibility guarantee covers and how to write integrations resilient to routine updates.
API versioning
Per-endpoint versioning in the URL path, and separate Semantic Versioning of the OpenAPI document.
Early Access
What Early Access means for production use, backward compatibility, and SLOs.
Was this page helpful?