SLA & Health

Real-time platform health status, active incidents, scheduled maintenance windows, and your partner SLA tier. Use it to drive status banners in your app or alert users when market data or order execution is degraded.

Service health

GET /sla

Returns overall platform health, any active incidents with severity and affected services, upcoming maintenance windows, and your SLA tier entitlements. Incidents are also broadcast via the incident.declared and incident.resolved webhooks.

Public status-page consumers can call GET /api/v1/status without partner credentials. It returns service health, active incidents, recent resolved incidents, and maintenance windows with public cache headers, while authenticated partners continue to receive incident webhooks and SSE events.

Published service objectives

SLOs are measured per calendar month from MyStocks server-side request and service-health telemetry. A successful API request is one that reaches the service and returns a non-5xx response; partner authentication, validation, rate-limit, market-closed, and insufficient-funds responses are not service failures.

For GA certification, authenticated non-streaming API traffic must sustain p95 response latency of at most 1 second and an error rate of at most 0.1% under the approved load profile. Regional failover recovery must complete within 60 seconds. Live market-order execution has a separate five-minute operational target while the relevant exchange is open; it is not an HTTP latency metric.

Planned maintenance announced at least 72 hours in advance, partner-side failures, exchange closures, and force-majeure upstream outages are reported separately. They are excluded from service-credit calculations only where the signed partner SLA explicitly permits it. Error-budget exhaustion freezes non-essential releases until reliability has recovered or an authorized exception is documented.

Order operations and execution expectations

An API acknowledgement is not an execution confirmation. A successfully accepted order enters PENDING and may remain there while the dealing team validates market status, buying power, restrictions, and the available execution venue. Build partner interfaces around the webhook-driven lifecycle rather than assuming an immediate fill.

Exchange sessions, holidays, early closes, and settlement dates vary by market. Use GET /market/status, GET /market/holidays, and GET /market/settlement instead of hard-coding local hours. A signed enterprise SLA can add named dealing coverage and escalation contacts; it does not turn a pending acknowledgement into a guaranteed fill.

For an order that exceeds the published objective, open a support case with the order ID and X-Request-ID. Do not submit a duplicate order. The support severity depends on customer impact and whether the relevant exchange is open.

curl "https://mystocks.africa/api/v1/partner/sla" \
  -H "Authorization: Bearer pk_live_<key>"

{
  "status": "OPERATIONAL",
  "tier": "starter",
  "incidents": [],
  "maintenance": [{ "id": "mnt_abc123", "title": "NGX data feed upgrade", "scheduledStart": "2026-06-15T02:00:00Z", "scheduledEnd": "2026-06-15T04:00:00Z", "affectedServices": ["market-data"], "status": "SCHEDULED" }],
  "services": [
    { "name": "Market Data", "status": "OPERATIONAL" },
    { "name": "Order Execution", "status": "OPERATIONAL" },
    { "name": "Webhooks", "status": "OPERATIONAL" },
    { "name": "Sub-Accounts", "status": "OPERATIONAL" }
  ],
  "checkedAt": "2026-06-09T10:00:00Z"
}

Incident severity levels