Reading Deprecation Notices
5 exercises — read a realistic SDK deprecation notice with a security rationale, migration path, and hard end-of-life deadline. Understand what is deprecated, why, and what action is required.
Reading deprecation notices: key elements
- What is deprecated → the specific methods, options, or endpoints being removed
- Why → the security or technical rationale for the change
- End-of-life date → the hard deadline after which the feature stops working
- Migration path → step-by-step replacement instructions
- Support contact → where to get help if migration is blocked
0 / 5 completed
1 / 5
Deprecation Notice — @acme/payments SDK
DEPRECATION NOTICE — @acme/payments SDK v2 Authentication API
Published: 2026-05-01 | Effective End-of-Life: 2027-01-31
---
WHAT IS DEPRECATED
The following methods in @acme/payments are deprecated as of v2.8.0:
- PaymentsClient.authenticate(apiKey)
- PaymentsClient.refreshToken(token)
- config.auth.legacyApiKey option
These methods rely on the legacy API key authentication scheme, which does
not support IP allowlisting, per-request scoping, or audit logging. They
will be REMOVED in v3.0.0, scheduled for release on 1 February 2027.
---
WHY WE ARE DEPRECATING
The legacy API key scheme has two significant limitations:
1. A single API key grants full account access. If compromised, all
payment operations are exposed until the key is manually rotated.
2. Keys do not expire automatically. Teams frequently leave test keys
active in production or fail to rotate after staff changes.
OAuth 2.0 client credentials (the replacement) addresses both: tokens
are scoped, short-lived, and generated per-environment.
---
MIGRATION PATH
Replace: PaymentsClient.authenticate(apiKey)
With: PaymentsClient.authenticateOAuth(clientId, clientSecret)
1. Generate OAuth credentials in the Dashboard under
Settings > API > OAuth Clients.
2. Store clientId and clientSecret in your secrets manager
(not in .env files committed to source control).
3. Replace all calls to authenticate() with authenticateOAuth().
4. Remove any config.auth.legacyApiKey entries from your config files.
5. Test against the sandbox environment before deploying.
Full migration guide: https://docs.acmepayments.io/migrate/oauth
---
SUPPORT
- Legacy API keys continue to work until 2027-01-31.
- After that date, any request using a legacy key will receive HTTP 401.
- For migration assistance, contact developer-support@acmepayments.io.According to this deprecation notice, what will happen on 1 February 2027?
Legacy keys stop working on 2027-01-31 — all requests return HTTP 401:
Two statements in the notice confirm this:
Why end-of-life dates are hard deadlines:
Unlike deprecation (still works, just warned), end-of-life is absolute. Any integration that has not migrated will stop working at midnight on 2027-01-31 — not gracefully degrade, not work in read-only mode, but completely fail.
Reading dates in deprecation notices:
Two statements in the notice confirm this:
- "They will be REMOVED in v3.0.0, scheduled for release on 1 February 2027"
- "After that date, any request using a legacy key will receive HTTP 401"
Why end-of-life dates are hard deadlines:
Unlike deprecation (still works, just warned), end-of-life is absolute. Any integration that has not migrated will stop working at midnight on 2027-01-31 — not gracefully degrade, not work in read-only mode, but completely fail.
Reading dates in deprecation notices:
- Published date (2026-05-01) → when the warning was issued
- Effective end-of-life (2027-01-31) → when the feature is removed
- Gap = 9 months notice — the time you have to complete migration