Deprecation Policy
How long each SDK major version and API version keeps working, how we give notice, what counts as a breaking change, and what happens to shipped app versions.
Each SDK major version and each API version keeps working for at least 12 months after its replacement ships. You get at least 90 days' email notice before anything stops working. This page defines both promises, the one exception for security fixes, and what to do about app versions that are already in users' hands.
The two commitments
| Commitment | What it means |
|---|---|
| 12-month support window | When a new SDK major version or a new API version ships, the one it replaces keeps working for at least 12 months from that release date. |
| 90-day notice | Before any change stops something working, we email you at least 90 days ahead. The notice states what changes, the date it takes effect, and what to do. |
The two run together, not in sequence. If version 2 ships on 1 March, version 1 keeps working until at least 1 March of the next year. We announce the stop date at least 90 days before it, so the notice can come at any time in that window but never later than 90 days before the date.
The same 90-day notice applies to other changes that need action from you, such as an app update to keep links opening your app. Terms section 6 states the commitment in contract terms.
What the commitments cover
- API versions. The REST API is versioned in its path. Today that is
/v1. - SDK major versions. The iOS, Android, React Native, and Flutter SDKs follow semantic versioning. A major version is the first number, so 1.1.0 belongs to major version 1.
- Calls that installed apps make. An SDK in a shipped app calls three endpoints:
GET /v1/sdk/validate,GET /v1/links/resolve/{slug}, andPOST /v1/attribution/match. The window protects those calls for as long as the SDK version that makes them is inside it.
Every SDK is on major version 1 and the API is v1. Nothing has been replaced, so no version is in a deprecation window today.
What counts as a breaking change
A change is breaking when code that worked before can stop working without being edited.
| Breaking | Not breaking |
|---|---|
| Removing or renaming an endpoint, a request field, or a response field | Adding an endpoint |
| Changing the type or the meaning of an existing field | Adding an optional request field |
| Rejecting a request that was accepted before, such as stricter validation | Adding a response field |
| Changing which keys or scopes an endpoint accepts | Fixing a bug where the old behavior contradicted the documentation |
| Removing a public method, type, or option from an SDK | Making a response faster or smaller without changing its fields |
| Ending support for a link host or link format that apps rely on | Adding a new SDK method or option |
Write your code to ignore response fields it does not know. We add fields without a version change.
Raising the minimum operating system or toolchain version in a new SDK release is announced in the changelog. It does not affect apps that stay on an older SDK release, because the older release is unchanged.
How notice is sent
- We email the account owner of each organization that could be affected. The email names the version, the stop date, and the replacement.
- We post the same notice in the changelog and mark the old version as deprecated in the documentation.
- The email is the notice that starts the 90 days. The changelog and the documentation are where you can check the date later.
We send the email to the address on your account. Keep it current, because that address is how the notice reaches you.
Security fixes
A vulnerability can force a change faster than 90 days. When that happens, we fix the problem on our servers first wherever we can, so that you do not need to ship anything. If a fix needs action from you, such as an SDK update, we email you as soon as the fix is ready and give as much notice as the risk allows. We say in the email why the notice is shorter.
App versions that are already shipped
An app that is installed keeps the SDK version you built into it until the user updates. You cannot change that code from the server. Three things follow.
- Inside the window, those apps keep resolving links and matching installs exactly as they did.
- After a version stops, its calls fail. The SDK reports the error to your
onLinkcallback and your app keeps running. See Fallbacks when the API is unreachable for how to handle that error gracefully. - Plan for the update curve. Many users run an old app version for months. Ship the SDK update early in the 12 months, check how many sessions still use the old version, and keep the fallback in place until that number is small.
Your own app analytics or crash reporting show which app versions are in use. Those numbers tell you when it is safe to drop the fallback.
Where announcements live
- The changelog for every deprecation, with its dates.
- Email to account owners, which starts the 90 days.
- This page, which states the policy and is the page to check for changes to the policy itself.
Related pages: Plan changes and billing transitions covers changes to your own plan, and Data portability and leaving WarpLink covers what happens if the service itself ends.
Plan Changes and Billing Transitions
What happens to redirects, SDK calls, analytics, and grace periods when you cancel, downgrade, miss a payment, pass a limit, or end the domain trial.
Abuse Protection and Threat Model
What an extracted SDK key can do, how fabricated installs, replay, and referral manipulation work, which controls exist, and how to verify rewards server-side.