Real-time alarm when the Ecwid REST API or webhook integration starts erroring above threshold.
At a glance
A detection-layer alert that fires when the share of failing calls to the Ecwid REST API or inbound webhooks crosses the threshold inside a rolling one-hour window. It is not a business KPI; it is an integration-health alarm. When this card lights up, the numbers on every other Ecwid card may be stale or incomplete, because the pipe that feeds them is broken. The usual causes are an expired OAuth token, a revoked scope, an Ecwid platform incident, or rate-limit throttling.
| What it tracks | The rolling error rate across calls Vortex IQ makes to the Ecwid REST API plus the inbound webhook deliveries it receives, measured over the last 1h. An error is any non-success HTTP response (4xx / 5xx), a timeout, or a malformed payload. |
| API endpoint | Synthetic across the connector’s traffic to GET /v3/{store-id}/... (orders, products, customers) and the webhook receiver for order.created, order.updated, order.paid, product.updated. No single endpoint; the card watches the connection itself. |
| What counts as a failure | HTTP 401 / 403 (auth / scope), 429 (rate limit), 5xx (Ecwid platform), connection timeout, and schema-mismatch payloads we cannot parse. |
| What it excludes | Expected empty results (a store with zero orders is not an error); single transient blips below the threshold; calls retried and succeeded inside the window. |
| Currency | Number. The card surfaces an error rate (percentage) and the count of failing calls; it is not a money metric. |
| Time window | RT (real-time, rolling 1h evaluation). |
| Alert trigger | API error rate >5% in last 1h. |
| Sentiment | Inverse gauge. Sensitive card; a non-zero reading is bad by definition, and the alert is the headline. |
| Roles | owner, engineering, operations. |
Calculation
Calculated automatically from your Ecwid 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 UK hobby seller running an Ecwid widget on a WordPress photography blog. The alert fires at 09:14 on 18 Mar 26. The merchant has not touched their integration in months. Overnight, Ecwid expired the OAuth access token that the connector uses to read orders, and the silent refresh failed because a scope had been narrowed during an Ecwid app-permissions update. What tripped:| Signal | Last 1h | Baseline | Status |
|---|---|---|---|
| API calls attempted | 142 | ~140 | normal |
| Calls failing (HTTP 401) | 131 | ~1 | spiking |
| Error rate | 92.3% | <1% | far above 5% trigger |
| Webhooks received | 0 | ~6 | stalled |
- Read the error class. A 401 / 403 cluster means auth or scope, not a sales problem. A 5xx cluster means Ecwid’s platform; check the Ecwid status page and wait. A 429 cluster means rate-limit throttling; the connector backs off automatically.
- For the 401 here, reconnect the Ecwid connector from Vortex IQ settings. This re-runs the OAuth handshake and re-grants the
read_orders,read_catalog, andread_customersscopes. - Confirm the error rate falls back under 5% within the next evaluation window and that webhook deliveries resume.
- If a 5xx incident, no merchant action fixes it; the card auto-clears once Ecwid recovers and the backfill completes.
Sibling cards merchants should reference together
| Card | Why it matters next to this alert | What the combination tells you |
|---|---|---|
| Total Revenue | The number most affected by a broken pipe. | If revenue looks frozen and this alert is live, the freeze is a sync artefact, not a real drop. |
| Order Volume | The fastest-moving feed. | Order volume flatlining at the same minute the alert fired confirms a pipeline stall, not demand. |
| Order Processing Backlog | Downstream of failed webhooks. | Missed order.created webhooks can hide a backlog that surfaces in a burst once sync recovers. |
| Inventory Sync Drift Across Storefronts | Stock feeds use the same API. | An API spike often co-fires with drift; stock numbers stop updating across surfaces. |
| Active Storefront Surfaces | Surface health. | If surfaces also drop off, the outage is upstream of one channel rather than the whole connector. |
| Channel-Specific Order Drop | Disambiguates scope. | A single-channel drop with a clean API rate points to that channel, not the connector. |
| Stock-Out Burst (>5 SKUs in <1h) | Shares the real-time layer. | A feed error can masquerade as a stock-out burst; check the API alert first. |
Reconciling against Ecwid
Where to look in Ecwid’s own dashboard:
Ecwid Control Panel (my.ecwid.com) -> Settings -> Apps -> Vortex IQ (or My Apps)
Confirm the app is still authorised and the granted scopes include order, catalogue, and customer read access. If the app shows as disconnected or a scope is missing, that is the root cause.
For platform-wide incidents, cross-check the Ecwid / Lightspeed status page; a 5xx cluster on this card usually maps to a posted incident there.
Why our number may differ from Ecwid’s Control Panel:
| Reason | Direction | Why |
|---|---|---|
| Vantage point | Ours only | Ecwid’s Control Panel does not show the health of a third-party app’s API calls; this alert is measured from our side of the connection. |
| Rate-limit handling | Ours higher transiently | Ecwid throttles heavy callers with 429s; we count those as failures until back-off succeeds, while Ecwid simply records a throttled request. |
| Webhook delivery | Ours only | A webhook Ecwid believes it sent but that never reached us counts as a failure here; Ecwid’s view shows it as delivered. |
| Evaluation lag | Boundary minutes | The 1h window rolls continuously; a spike at the very edge of the hour may read slightly differently than a static Ecwid log slice. |
ecwid_api_failure_rate = failing_calls_1h / total_calls_1h, evaluated continuously; the alert fires above 5%.