BTP & Integrationadvanced

BTP API Management Part 6: Product Lifecycle, Versioning, Analytics and Developer Portal

Key takeaway

Run APIs as products: versioning strategy (URI versions), deprecation and retirement with analytics-driven communication, products and applications in the developer portal, API documentation, analytics for usage and errors, and governance roles.

Explanation

📌 KEY POINTS
✅ Version APIs explicitly (e.g. /v1, /v2) and avoid breaking changes within a version.
✅ Deprecate with dates, communicate via the portal, and use analytics to see who still calls old versions.
✅ Products define what consumers get (APIs, quotas); applications hold credentials.
✅ Analytics show usage, errors and latency per API, product and app.
⚠️ Retiring a version without checking analytics breaks consumers you didn't know about.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 5 covered traffic. Now lifecycle.

━━━━━━━━━━━━━━━━━━━━
▶ 1. VERSIONING

URI versions; compatibility rules.

━━━━━━━━━━━━━━━━━━━━
▶ 2. DEPRECATION

Timeline, communication, headers.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PRODUCTS & APPS

Bundles, tiers, approvals.

━━━━━━━━━━━━━━━━━━━━
▶ 4. PORTAL & DOCS

OpenAPI docs, examples, onboarding.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ANALYTICS & GOVERNANCE

Usage review, owners, reviews.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Publish v2 alongside v1.
Mark v1 deprecated with a sunset date.
Use analytics to contact remaining v1 consumers.

✅ CHECKPOINT: v1 retired with zero active consumers.

Code example

ABAP Code

===== LIFECYCLE =====v1 live → v2 published (new product revision) → v1 deprecated (Sunset: 2026-12-31 header, portal notice) → analytics: apps still calling v1 → contact owners → v1 retired ===== PORTAL =====Product "Orders API (Partner)" → APIs: orders v2 | quota 50,000/day | approval requiredDocs: OpenAPI spec, examples, error catalog

Real project scenario

An API team wanted to retire v1 but didn't know who used it. Analytics showed three partner apps; direct communication and a sunset header allowed a clean retirement without outages.

Common mistakes

Breaking changes in versions.
Silent retirement.
No docs.
No owners.
Ignoring analytics.

Best practices

Explicit versions.
Communicated deprecation.
Rich docs.
API owners.
Analytics reviews.

Interview angle

Questions: "How do you version APIs?", "How do you retire an API?", "What does analytics give you?"
Strong answer: versioning, deprecation, products/portal, analytics, governance.

Practice this lesson

Quick check

1. A small field rename is needed in a live API. What is the right approach?

2. An API team wants to retire v1 but doesn't know who uses it. What should they do first?

3. What business value do the Analytics/Reports capabilities in SAP API Management provide to API providers?

Interview questions

1. How do you manage the lifecycle of APIs as products, including retiring old versions?

Answer it in your own words first, then compare.

2. Suppose you inherit an existing API Management solution. How would you review it before making a change?