SCC integrations break hard on version EOL - surfaces replatform-grade engineering concerns.
At a glance
A two-condition engineering alert on the health of your Salesforce Commerce Cloud (SFCC, formerly Demandware) API layer. It fires when either the OCAPI / SCAPI error rate spikes above a healthy level in the last hour, the “something is failing right now” condition, or when any connected integration is sitting on an API version whose end-of-life is imminent, the “this is about to break” condition. SFCC integrations do not degrade gracefully on version retirement; they stop. This card is designed to catch both the live incident and the slow-moving cliff before checkout, order flow, or a LINK cartridge goes down with it.
| What it counts | Two distinct signals surfaced on one card. (1) The OCAPI (Open Commerce API) / SCAPI (Salesforce Commerce API) request error rate over the last hour, the share of API calls returning failures. (2) The number of connected integrations running on an API version flagged for retirement within the warning window. |
| Why it matters | The API layer is the spine of a headless or integrated SFCC estate: storefront, checkout, OMS sync, payment cartridges, and middleware all ride OCAPI / SCAPI. A live error spike means transactions are failing now. An imminent EOL means a hard break is scheduled, and unlike a deprecation warning, SFCC version retirement actually removes the endpoint. This is replatform-grade engineering risk surfaced as an operational alert. |
| Reading the value | Treat any fire as an engineering page. For the error-rate condition, the figure is the failure percentage; a spike is the signal, not the absolute level. For the EOL condition, the figure is the count of integrations on a soon-to-be-retired version; each one is a scheduled outage unless upgraded. |
| What it is not | It is not a general latency monitor and not a business KPI. It is a hard-failure and hard-deadline signal. A slow but successful API will not fire the error condition; a version with a distant EOL will not fire the deadline condition. |
| Two conditions, one card | The card fires on either condition independently. A fire could be a live spike with no EOL risk, an EOL warning with healthy traffic, or both at once. Always read which condition tripped before responding; they need different fixes. |
| Unit | number (error-rate percentage for the spike condition; integration count for the EOL condition) |
| Time window | RT (1-hour error-rate window; live EOL-schedule check) |
| Alert trigger | API error rate >2% in last 1h OR any integration on version EOL <30d |
| Sentiment key | scc_alert_api_failure_rate_spike |
| Roles | owner, engineering, operations |
Calculation
Calculated automatically from your Salesforce Commerce Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A retailer runs an SFCC B2C realm with a headless React storefront on SCAPI, a legacy ISML site on OCAPI, and several LINK cartridges (payment, OMS, tax) calling the order APIs. Two separate fires in one week:| Date | Condition that tripped | Reading | Cause |
|---|---|---|---|
| 10 Jun 26, 14:05 | Error-rate spike | 6.4% of SCAPI calls failing in the hour (baseline ~0.3%) | Expired OAuth client credential on the headless storefront’s SCAPI client |
| 12 Jun 26, 09:00 | Version EOL imminent | 2 integrations on an OCAPI version retiring in 21 days | A payment LINK cartridge and a custom OMS bridge both pinned to a deprecated OCAPI version |
- Two fires, two completely different problems. The 10 Jun fire is a live incident, checkout calls are failing right now, and the fix is a credential rotation measured in minutes. The 12 Jun fire is a deadline, nothing is failing yet, and the fix is an engineering change measured in sprints. Same card, opposite urgency profiles. Always read the condition first.
- The error spike is concentrated, not spread. 6.4% sounds survivable until you see it is all on the headless storefront’s SCAPI client. The legacy OCAPI site is fine. A spike on one client/cartridge points straight at that integration’s config, an expired credential, a quota breach, or a bad deploy, rather than an SFCC-wide outage.
- The EOL condition fires with healthy traffic. On 12 Jun the APIs are working perfectly; nothing is broken. The card still fired because two integrations are 21 days from a hard cutoff. This is the value of the second condition: it surfaces the cliff while you still have time to climb down, instead of at 00:01 on retirement day when the endpoint vanishes.
- Both feed forward into realm risk. A live spike on the order APIs and an imminent EOL on a checkout cartridge are both leading indicators that order flow is about to suffer. They surface as forward exposure in Revenue at Risk (live) and connect to the standing version inventory in Integrations on EOLd / EOL-Soon Versions.
Sibling cards merchants should reference together
| Card | Why pair it with this alert |
|---|---|
| API Version Status (OCAPI / SCAPI) | The standing status view behind the EOL condition. When this alert fires on an imminent EOL, this card tells you which versions each integration is on and how far they are from retirement. |
| Integrations on EOLd / EOL-Soon Versions | The full inventory of at-risk integrations. The alert flags the imminent ones; this card lists everything trending toward a cliff so you can plan upgrades ahead of the fire. |
| OCAPI vs SCAPI Usage Mix | Shows how much traffic rides the legacy OCAPI surface vs modern SCAPI. A spike or EOL on the heavily-used surface is far more serious; this card sizes the blast radius. |
| Revenue at Risk (live) | Translates an API spike or imminent EOL on the order/checkout APIs into a revenue exposure figure for owners and finance. |
| Failed Orders (24h) | A downstream symptom: when order-API calls fail, orders land in FAILED. Correlated fires confirm the spike is hitting checkout. |
| Orders Awaiting Downstream Sync (24h) | If an OMS or middleware cartridge is on a failing or retiring version, orders stop syncing; a backlog here often shares this alert’s root cause. |
Reconciling against Salesforce Commerce Cloud
Where to look in Business Manager: There is no single Business Manager report that equals this card, because it stitches together live API error-rate telemetry and the version-retirement schedule, which SFCC exposes in different places (and partly in Salesforce’s published roadmap, not Business Manager at all). To verify each condition:- Error-rate spike: Administration, Site Development, OCAPI Settings (and the SCAPI / Account Manager configuration) shows the configured clients; SFCC’s API logs and the Log Center / request logs show the actual error responses over the window. Your APIM or middleware logs are often the fastest place to see the failing client and status codes.
- Imminent EOL: cross-check the OCAPI / SCAPI versions configured for each client against Salesforce’s published API version lifecycle and deprecation schedule (Salesforce documents OCAPI version support windows and SCAPI versioning). The retirement date is a Salesforce roadmap fact, not a Business Manager field.
- Which integrations are affected: Administration, Site Development, and the OCAPI client configuration list the registered clients and their versions; pair with your own cartridge inventory (LINK cartridges, custom bridges) to map each client to an integration.
| Reason | Direction of divergence |
|---|---|
| Telemetry source. Vortex IQ reads API success/failure as observed; Business Manager / Log Center reports may sample or aggregate differently, so the exact error percentage can vary. | ±small on the percentage |
| Window alignment. The spike condition is a rolling 1-hour window; BM and log views use their own time buckets and time zone. | Boundary differences |
| EOL is a schedule, not a count. No BM report shows “integrations within 30 days of EOL”; this card computes it from version + Salesforce’s published retirement dates. | Not directly comparable |
| Client vs integration mapping. SFCC registers API clients; mapping a client to a business integration (a cartridge, a storefront) depends on your own inventory. | Naming/scope differences |
| Sandbox vs production. Error spikes or version pins on a sandbox realm should not appear on a production-only Vortex IQ workspace; if they do, check the connected realm. | Possible scope mismatch |