ShippyPro’s core SLA - did label generation succeed across the carrier mix?
At a glance
Share of label-creation API calls in the last 24 hours that returned a valid printable shipping label. The single most-actionable connector-health number for ShippyPro: when this drops below 98%, orders cannot be despatched, regardless of how healthy the carriers, the warehouse, or the rate-shop ruleset are. The fault is between Vortex IQ and ShippyPro, or between ShippyPro and the underlying carriers.
| What it counts | COUNT(label_create_calls WHERE status = 'success') / COUNT(label_create_calls) over the trailing 24 hours. Each call is one label attempt; retries count as separate calls. |
| API endpoint | POST /shipments/labels (ShippyPro’s label-creation endpoint). The card reads HTTP response code and parsed success flag from each attempt. |
| Failure modes counted | (1) Carrier downtime, the underlying carrier API rejected the rate-shop call. (2) ShippyPro internal errors, 5xx from ShippyPro itself. (3) Validation errors, invalid address, invalid weight, missing customs declaration on cross-border. (4) Auth errors, 401 from expired token (links to Days to Token Expiry). |
| Carrier-mix sensitivity | Failures are not uniformly distributed. Italian and EU regional carriers (Poste Italiane, BRT) have higher native API instability than majors (DHL Express, GLS, UPS). A 95% reading on a Poste-heavy account often resolves to 99% if Poste is excluded. |
| Returns / RTO | Includes Easy Return label generation; treats them identically to outbound. |
| Service level scope | All services and carriers pooled. Per-carrier breakdown lives in the carrier sub-tile of the same card. |
| Currency | Not applicable. |
| Time window | 24H (rolling 24-hour window) |
| Alert trigger | <98%. Tripped when success rate drops below 98 percent. The 2 percent cushion is industry-standard for label-print SLA; below that, despatch operations notice queue stall. |
| Sentiment key | label_generation_success |
| Roles | owner, operations |
Calculation
Calculated automatically from your ShippyPro data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The Italian DTC fashion brand. Reading taken at 09:00 CET on 12 Mar 26 for the trailing 24 hours.| Carrier | Label calls (24h) | Successful | Failures | Success rate | Most common failure |
|---|---|---|---|---|---|
| BRT | 920 | 916 | 4 | 99.6% | Address validation |
| DHL Express | 410 | 410 | 0 | 100.0% | (none) |
| GLS | 380 | 376 | 4 | 98.9% | Carrier 5xx |
| Poste Italiane | 240 | 218 | 22 | 90.8% | Carrier 503 (downtime) |
| UPS | 60 | 60 | 0 | 100.0% | (none) |
| All carriers (this card) | 2,010 | 1,980 | 30 | 98.5% |
<98% is not firing at the aggregate but Poste Italiane alone is materially below. Five things to notice:
- Poste Italiane’s 90.8% drags the aggregate down by 1.4 points. If Poste volume rises (rate-shop swings to it for cheap parcels), the aggregate drops below 98% even with no other change. The aggregate masks the per-carrier instability; per-carrier sub-tiles are mandatory reading.
- 22 Poste failures over 24 hours = 22 orders that could not despatch. They sit in the warehouse queue waiting for retry. The operational fix during a Poste downtime is to override rate-shop temporarily to BRT for those parcels (at 30 to 50 percent higher per-label cost) and despatch. The card is the trigger for the override decision.
- DHL Express and UPS at 100% are the carrier-network benchmark. If they ever drop below 99%, the issue is almost certainly ShippyPro-side or your-account-side, not carrier-side. Use them as the control.
- The 4 BRT and 4 GLS failures are noise-floor. Under 1 percent failure on healthy carriers is normal; address-validation rejections (postcode does not match city, missing house number) account for most. They retry successfully on next attempt; the 24-hour window absorbs them.
- Aggregate 98.5% is the intervention threshold. At 98% exact, queue stall is visible to despatch staff (~10 to 30 orders waiting at any moment); at 95%, full operations escalation; at 90%, P1 incident regardless of which carrier is failing. The card’s alert at 98% is calibrated for the first-detection signal, not the visible-pain threshold.
Sibling cards merchants should reference together
Label-generation success is the gate; many other cards depend on it being green. Pair with these:| Card | Why pair it with Label Generation Success | What the combination tells you |
|---|---|---|
| Days to Token Expiry | Token expiry produces 100 percent failure with 401 errors. | Both cards red simultaneously = expired token, rotate immediately. |
| API Error Rate | Same underlying signal, different angle. | Error rate climbing while label success is dropping = carrier-side or ShippyPro-side issue. |
| Shipments | Volume processed; reflects label-success in absolute terms. | Volume drop without label-success drop = upstream order-flow drop (not connector). Volume drop with label-success drop = connector issue. |
| OTD by Route | Per-carrier breakdown context. | If a carrier’s label success is degrading, watch its OTD; carrier API instability often correlates with carrier physical-network issues. |
Cross-connector: shopify.unfulfilled_orders | Downstream impact. Failed labels = unfulfilled orders piling up in Shopify. | Climbing Shopify unfulfilled is the customer-visible symptom of label-generation drop. |
| Cross-connector: warehouse-management system queue depth | Direct operational view of orders waiting for label. | Queue stalling without label-success drop = warehouse-side problem. Queue stalling with label-success drop = ShippyPro-side problem. |
Reconciling against the vendor’s own dashboard
Where to look in ShippyPro’s own dashboard: ShippyPro Dashboard → API Health → Label Creation Stats (not always exposed by default; visible to enterprise tier or by support request). The closest like-for-like is Last 24h, All Carriers, All Services. ShippyPro also exposes a per-call audit log at Logs → API Calls → Filter type:label_create that shows the actual error response per failure. Why our number may legitimately differ from ShippyPro’s portal:| Reason | Direction | Why |
|---|---|---|
| Retry counting | Ours sometimes lower | The card counts each retry as a separate attempt; some portal views collapse retries into a single “shipment” outcome. If a label took 3 attempts to succeed, the card scores 2 failures and 1 success (66.7% on that shipment); the portal may show 100% (the shipment ultimately got a label). |
| Internal-error attribution | Either | ShippyPro classifies some 5xx errors as carrier-side, others as ShippyPro-side; the card pools them. Different filter states in the portal may show different denominators. |
| Validation pre-check | Ours sometimes higher | If your client-side validation rejects a label before submitting (e.g. weight = 0), the card never sees it; ShippyPro’s portal may show it as a “rejected” attempt. |
| Timezone | Boundary hour off | Card defaults to UTC; portal defaults to workspace timezone. The 24h boundary shifts. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
shopify.unfulfilled_orders | Downstream effect; label-failure drops directly raise unfulfilled count. | Manual fulfilment, B2B flows, Shopify-app retry behaviours that mask the label failure. |
| Direct carrier status pages (DHL service status, BRT alerts) | Upstream truth on carrier-side downtime. | Carriers post outage notices on their status pages; correlate to the timestamped failures in the card’s audit log. |