Status Monitoring API
Machine-readable feed status, source-health score, and customer-visible incident summaries for production integrations.
Section
15 / 27
Live API examples
Jump from the docs to real public pages that use the same read models.
Endpoints
/v1/statusCompact feed health, source-health, and public incident summary.
When to call status
Use /v1/status for lightweight health monitoring, customer support dashboards, and deployment smoke checks. It summarizes collection buckets, freshness policy, source health, and public incidents while excluding private collection diagnostics and credentials.
curl -sS "https://api.lotteryfeedapi.com/v1/status" \ -H "Authorization: Bearer YOUR_API_KEY"
Source health score
source_health is a public reliability summary from current collection status buckets. Scores are evidence-backed but not an SLA. Treat strong, watch, and degraded as customer-visible monitoring labels; use the evidence counts to decide whether to show an operational banner or pause aggressive polling.
{
"source_health": {
"score": 84,
"grade": "watch",
"label": "Source watch",
"evidence": [
{ "label": "On track or waiting", "value": 168, "tone": "success" },
{ "label": "Monitoring window", "value": 6, "tone": "warning" },
{ "label": "Blocked or failing", "value": 2, "tone": "danger" }
],
"policy": {
"headline": "Source health uses public collection buckets only",
"incidentRule": "A source warning becomes a public incident only after blocked, failing, or late rows cross the public threshold and can affect customer-visible result delivery."
}
}
}Freshness policy
freshness_policy is the short customer-visible interpretation of delivery levels for status screens. F1-F7 describe plan delivery delay after feed storage; upstream publication and ingestion are separate.
{
"freshness_policy": {
"headline": "Plan delivery delays are separate from ingestion and uptime",
"summary": "The status page separates source publication, feed ingestion, plan delivery delay, and public cache refresh.",
"bullets": [
{
"label": "Clock start",
"text": "Plan delivery delay starts after the feed first stores or observes a result."
},
{
"label": "No guarantee",
"text": "F1-F7 are plan delivery-delay policies, not ingestion or uptime guarantees."
}
],
"links": [
{ "label": "Compare delivery plans", "href": "/pricing" },
{ "label": "Read status API docs", "href": "/api-docs/status" }
]
}
}Data freshness warning
data_freshness is a compact schedule-aware signal derived from expected draw-window states. Latest draw dates are context only, so weekly or day-specific games are not marked stale by a fixed age threshold.
{
"data_freshness": {
"status": "degraded",
"label": "Some scheduled results need attention",
"summary": "12 of 182 customer-visible games are late, blocked, or failing against their expected draw windows.",
"latest_draw_date": "2026-06-20",
"latest_age_days": 5,
"checked_games": 182,
"current_games": 170,
"degraded_games": 12,
"unknown_games": 0,
"examples": [
{
"name": "Maryland Pick 3 Midday",
"latest_draw_date": "2026-06-20",
"age_days": 5,
"status": "late",
"status_label": "Late"
}
],
"disclosure": "This customer-facing signal uses expected draw-window states. Latest draw dates are context only."
}
}Live channel readiness
live_channel reports whether a public streaming subscription is available. When can_subscribe is false, use bounded latest-result polling or request reviewed webhook access. No streaming subscription URL is published before the feature is available.
{
"live_channel": {
"status": "not_available",
"label": "Streaming subscriptions are not currently available",
"can_subscribe": false,
"summary": "Streaming subscriptions are not currently available.",
"safe_alternatives": [
{
"label": "Poll latest results",
"href": "/api-docs/results",
"detail": "Use GET /v1/results/latest with normal cache and retry behavior for customer applications."
},
{
"label": "Request webhook access",
"href": "/contact?use_case=webhook-access",
"detail": "Request a workspace review before using signed push delivery for created, updated, or corrected draws."
},
{
"label": "Monitor feed status",
"href": "/api-docs/status",
"detail": "Use GET /v1/status for compact source-health, freshness policy, and public incident summaries."
}
]
}
}Incident lifecycle summary
incident_history describes the customer-visible incident log: whether a published history exists, when it was last updated, how many public rows are retained, and how many open or resolved incidents are visible. It deliberately excludes private warnings and infrastructure error details.
{
"incident_history": {
"source_label": "Published incident log",
"configured": true,
"updated_at": "2026-06-25T12:16:00.000Z",
"total_incidents": 2,
"open_incidents": 1,
"resolved_incidents": 1,
"latest_started_at": "2026-06-25T11:00:00.000Z",
"max_rows": 12,
"disclosure": "Public incident history is a bounded customer-visible lifecycle log. Source-specific diagnostics stay private."
}
}Public incidents
incidents contains only customer-visible service issues. Individual source warnings may remain private until they affect customer-visible delivery. When an incident appears, store its id, status, severity, startedAt, impact, and customerAction so your own status page can explain whether customers should retry, wait for webhook delivery, or rely on cached results.
{
"incidents": [
{
"id": "active-source-access-degradation",
"title": "Source access degradation under review",
"status": "identified",
"severity": "minor",
"startedAt": "2026-06-20T00:00:00.000Z",
"summary": "3 tracked lottery rows are blocked or repeatedly failing in the current public snapshot.",
"impact": "Some latest-result and history rows can be delayed until an official source recovers or an approved fallback path is used.",
"customerAction": "Keep API and webhook consumers idempotent, use cached latest results where acceptable, and monitor this page for recovery."
}
]
}Optional game rows
By default, /v1/status returns summary data only. Add include=games only for screens that need current customer-visible game rows, pass limit to keep the UI bounded, and follow games_next for the next slice. Rows are deliberately compact and exclude private source diagnostics. Do not use status polling as a replacement for latest-result endpoints or webhook delivery.
{
"games_count": 1,
"games_total_count": 2,
"games_limit": 1,
"games_offset": 0,
"games_has_more": true,
"games_next": "/v1/status?include=games&limit=1&offset=1",
"games": [
{
"game_code": "on-pick3-midday",
"name": "Ontario Pick 3 Midday",
"status": "blocked",
"status_label": "Source access blocked",
"latest_draw_date": "2026-06-20",
"tone": "danger"
}
]
}API documentation FAQ
Short answers for teams using status monitoring api in production integrations.
Is source_health an SLA?
No. source_health is a public monitoring summary. F1-F7 describe plan delivery delay after feed storage, not ingestion or uptime guarantees.
Do incidents include raw source errors?
No. Public incidents contain customer-visible summaries, impact, lifecycle status, and action guidance only.
Next: Rate limiting