Version lifecycle
You cannot safely remove what you cannot see. EndPointBlank holds the lifecycle state of every endpoint version alongside the record of who is actually still calling it — so deprecation stops being a guess followed by an apology.
Turning off v1
means answering one question: who breaks? Most teams answer it by announcing a date,
waiting, and hoping — because the version state lives in a changelog, the usage data
lives in a monitoring tool, and nothing joins them together.
So deprecation gets deferred. Old versions accumulate, every one of them a thing you must keep working, and the cost of the next breaking change goes up.
Both ends of the lifecycle are derived from where a version is actually deployed. The only judgement a person makes is the one in the middle.
| Status | How it is reached | Set by |
|---|---|---|
| In development | First deploy to a non-production environment | Derived |
| Current | Deployed to production, nothing declared against it | Derived |
| Deprecated | Someone deprecates it in the portal | Declared |
| Retires in N days | A deprecation that has committed to a date | Declared |
| Retired | It left production, having been deprecated first | Derived |
Mark v1
deprecated in the portal and your consumers are told. No branch, no pull request, no
waiting for your next deploy window.
That matters more than it sounds. When the deprecation itself requires shipping code, it competes with feature work and loses — which is exactly why old versions survive years past their usefulness.
Attach a date and the version reads Retires in 30 days to you and to every consumer, with reminders as it approaches. Cancel the date and the version stays deprecated — it is still on its way out, it just no longer has a deadline. Returning it to Current is a separate, deliberate act.
Individual endpoints can be excused from the version-wide schedule when one of them needs longer, and a date set on a single endpoint outlives a version-wide cancel.
A version production no longer serves is retired, not schedulable. Deprecation and promotion to Current are both gated on the version actually being in production, so the portal will not let you schedule the retirement of something that has already retired itself.
The same rule going the other way: a version that leaves production having been deprecated first is retired automatically, and announced. Nobody maintains that bookkeeping by hand.
Every authorization records the calling service and the endpoint version it asked for.
So the list of clients still on
v1
is a query, not a guess — and because the same system holds the credential
relationship, those specific consumers can be notified from the same screen.
Sign up in under a minute. No credit card, no sales call.