Only for features you can switch off or degrade without harming customers. A preview or beta API can change behavior, limits, or availability on the vendor's schedule. Read the vendor's terms for change and retirement notice, write a fallback, and keep the feature out of any commitment you cannot keep.
What preview status usually means
The word means different things at different vendors, so read the vendor's own definition rather than assuming. Questions to answer from the documentation or contract:
- Is there a stability or deprecation promise?
- How much notice is given before changes or retirement?
- Are there different data handling, retention, or support terms?
- Is the preview covered by the same agreement as the general product?
If the documents do not say, treat that as an answer and plan for sudden change.
Risk checklist
| Risk | Question |
|---|---|
| Behavior change | Would a silent change break the feature or alter outputs? |
| Retirement | Could the API end with short notice? |
| Data handling | Are the data terms the same as for the stable product? |
| Support | Who do we call if it fails? |
| Compliance | Does a customer commitment depend on it? |
Design for removal
- Put the vendor behind an interface you own, so a swap changes one module.
- Place the feature behind a flag you can turn off quickly.
- Define the degraded experience: hide the feature, use a simpler method, or queue work.
- Test the fallback, not just write it down.
- Pin versions where the vendor allows it, and record the version you tested.
Keep it out of promises
Do not put a preview feature into a contract, a public roadmap date, or a security questionnaire answer as if it were stable. If sales wants to show it, label it clearly as preview with no commitments.
Set a graduation review
Put a date on the roadmap to ask: has the vendor moved this to general availability, and are the terms better? Either promote the dependency or plan the exit. A preview dependency that nobody reviews tends to become permanent by accident.
Document the decision
Record the vendor, the status, the terms you read, the fallback, and the owner. When a preview ends, that note saves a scramble.
Tell the people who depend on you
If another team or a customer builds on your preview powered feature, tell them what it rests on. A short note in the release notes saying the feature relies on a vendor preview, and what you will do if it ends, sets honest expectations and avoids anger later.
Quick check
Is it fine to use a preview API for an internal tool?
Often yes, because failure affects fewer people. Still note the dependency and the owner.
Should security questionnaires mention preview features?
Only if asked, and label them clearly. Do not describe them as stable controls.
Safeguard's asset discovery and SBOM scanning help keep an inventory of external services and components, and the free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
