OCAPI / SCAPI Failure Rate Spike OR Version EOL Imminent, Salesforce Commerce Cloud

OCAPI / SCAPI Failure Rate Spike OR Version EOL Imminent, an alert that fires on an API error spike or an imminent version retirement. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Ecommerce Platform

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

Things to notice:

1. 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.
2. 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.
3. 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.
4. 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.

Because the error condition is live telemetry and the EOL condition is a schedule check, treat Business Manager and Salesforce’s lifecycle docs as the place to confirm the cause, not to match a single headline number.

Why our number may legitimately differ from Business Manager:

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

Known limitations / merchant FAQs

Why are an error spike and a version EOL on the same card? Because both are hard-failure signals about the same layer, the OCAPI / SCAPI API surface that everything else rides, and an owner or engineering lead wants a single “the API spine is in trouble” flag. They differ in timing (one is failing now, one is scheduled to fail) but not in seriousness. The card fires on either condition independently, and the detail tells you which tripped so you can respond correctly.

The card fired but nothing seems broken. Which condition was it? Almost certainly the EOL condition. SFCC API versions do not degrade before retirement, they work perfectly right up to the cutoff, then the endpoint is removed. A fire with healthy traffic means an integration is inside the warning window for a version retirement. That is exactly when you want to know, while there is still time to upgrade. Check API Version Status for the specifics.

Why does SFCC version EOL break things so hard? Unlike many APIs that keep deprecated versions running indefinitely behind a warning, Salesforce retires OCAPI / SCAPI versions on a published schedule and removes them. An integration pinned to a retired version stops getting valid responses, it does not fall back to a newer version automatically. For checkout, payment, or OMS cartridges that is a hard outage. This is why the card frames it as replatform-grade engineering risk rather than a tidy-up task.

What counts as an error for the spike condition? Failed API responses over the rolling hour, as a share of total calls. The default trigger is above 2% in the last hour. The signal that matters is the spike relative to your baseline (often well under 1%), not the absolute number. A spike concentrated on one client or cartridge points at that integration’s config (credentials, quota, a bad deploy); a spike across all clients points at a broader SFCC or network event.

Can I tune the thresholds? Yes. Both the error-rate threshold (default >2% in 1h) and the EOL warning window (default <30 days) are configurable per profile in the Alert Rules tab. A high-traffic realm with a sensitive checkout may want a tighter error threshold; a team that plans upgrades far ahead may want a longer EOL warning window so the fire lands with more runway.

An error spike fired on one cartridge only. Is the whole realm at risk? Not necessarily, and that detail is the useful part. A spike isolated to a single SCAPI client or LINK cartridge usually means that integration’s configuration is the problem, not SFCC itself. Other storefronts and cartridges keep working. Read OCAPI vs SCAPI Usage Mix to judge how much traffic the failing surface carries before deciding how hard to escalate.

How do I see the business impact, not just the engineering signal? This card is the engineering alert. For the money, a live spike or imminent EOL on the order/checkout APIs feeds Revenue at Risk (live), and the downstream symptoms show up in Failed Orders (24h) and the sync backlog cards. Read those together to take the issue from “the API is failing” to “here is what it is costing”.

---

Tracked live in Vortex IQ Nerve Centre

OCAPI / SCAPI Failure Rate Spike OR Version EOL Imminent is one of hundreds of KPI pulses Vortex IQ tracks across Salesforce Commerce Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.