Early Access
Early Access is the first stage in the Infobip product lifecycle, before General Availability. Products and features in Early Access have completed development but are still being refined based on real-world usage and customer feedback.
The lifecycle has four stages, and each stage carries different guarantees:
- Early Access
- General Availability
- Deprecated
- Sunset
What Early Access means for you
During Early Access, you can use a product, including in production, while it is still being refined based on real-world usage and your feedback. The API is stable and the product is ready to use. What is still evolving is the breadth of features and the pace of change, both driven by the feedback gathered during this phase. That feedback is the point of Early Access, so real usage (production included) is expected and welcome.
The following table compares Early Access and General Availability.
| Aspect | Early Access | General Availability |
|---|---|---|
| Production use | Supported (see the backward compatibility and SLO rows) | Production-ready |
| API stability | Stable | Stable |
| Feature set | Usable, but breadth might be limited (for example, no full channel parity). See Features and availability. | Settled, documented scope that still grows over time |
| Backward compatibility | Not formally guaranteed. Breaking changes are possible if feedback redirects the API. See Production use and stability. | Guaranteed |
| Service-level objectives (SLOs) | Runs on Infobip production infrastructure and is monitored. Infobip commits to a formal SLO target at General Availability. | Committed |
| Regional availability | Varies by product. Confirm in the product documentation. | Available across regions, with any exceptions documented |
| Configuration and data kept after General Availability | Usually preserved. In rare cases, a migration is needed, always with notice and help. | Preserved |
| Product documentation | Yes | Yes |
| Support | Best-effort, with any limitations documented | Standard |
Production use and stability [#production-use-and-stability-what-early-access-means-for-you]
Early Access products are built to be used in production. That is how Infobip gathers feedback that moves the products toward General Availability, so it is not a "do not use in production" stage. The API is production-grade and behaves consistently from one call to the next. Stable does not mean the API can never change: fields, parameters, and behavior can still be adjusted during Early Access. For full details, see API versioning.
A breaking change is possible only if feedback shows that the API needs to change direction. Infobip avoids breaking changes unless necessary and always gives advance notice and migration help. Build without assuming the interface is frozen, and keep a rollback path, because backward compatibility is not formally guaranteed during Early Access.
Features and availability [#features-and-availability-what-early-access-means-for-you]
Narrower breadth is not the same as "unfinished". An endpoint might not cover every channel or sender type. Breadth is not what keeps a product in Early Access: a product graduates on stability, backward compatibility, SLOs, documentation, and support. Before you depend on a product, confirm in the product documentation what it supports and that it is available in your region.
Performance, data, and support [#performance-data-and-support-what-early-access-means-for-you]
Early Access products run on the same production infrastructure as Generally Available ones and are actively monitored, so day-to-day performance is typically strong. What differs from General Availability is a formal SLO target, such as a specific uptime or latency commitment. That target is finalized as the product graduates, rather than committed during Early Access. Any known limitations are documented.
Senders, webhooks, templates, and other setup normally carry over to General Availability. If a migration is ever needed, Infobip gives notice and helps you through it. Support is best-effort while the team gains experience with the product, but you still have full documentation, and your feedback directly shapes the product.
Cost: Pricing depends on the product, not on its lifecycle stage. An Early Access product can be free or paid, the same as at General Availability. Check the documentation of the product for its pricing.
How to recognize and access Early Access products
Early Access products and features are labeled so you can identify them before you build:
- Documentation: Early Access pages and sections carry an Early Access label.
- API reference and web interface: Affected endpoints carry an Early Access badge, and any requirement to request access is called out on the endpoint.
- Release notes: Early Access launches and graduations to General Availability are announced in the release notes.
Knowing that a product is in Early Access tells you two things. First, it carries different guarantees (see What Early Access means for you). Second, you might need to request access before you can use it.
Products available immediately: Most Early Access products are available immediately. Unless the product documentation or API reference says otherwise, you can use the product directly. Call the endpoint or turn on the product in the Infobip web interface. No request or setup is needed.
Gated products: Some Early Access products are gated, which means you must request access first. For example, a product can be gated where capacity, regulatory, or region constraints apply. A gated product states this explicitly in both its documentation and the API reference for the affected endpoints.
A public page describes the product and how to request access. The full setup and usage details might follow only after access is granted. To request access, contact your account manager or Support.
Provide feedback
Customer feedback is essential during Early Access. If you encounter an issue, have a request, or want to share an observation, contact your account manager or Support. Feedback during this phase directly influences the product before it reaches General Availability.
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.
Deprecation
The endpoint deprecation process, notification signals, and how the sunset date is set and communicated.
Was this page helpful?