Skip to content
Lottery Feed API

Lottery Feed API

ResultsPersonalAPI DocsPricingContact
Sign inJoin the Free Beta
  1. Home
  2. /
  3. API docs
  4. /
  5. Source Confidence Labels

API documentation

Source Confidence Labels

How official, verified, observer, fallback, manual, and unknown source-confidence labels should be interpreted.

Section

14 / 27

OpenAPI JSON
01Introduction02Quickstart03Polling and integration04Sandbox fixtures05SDK starter06Embeddable widgets07API playground08OpenAPI spec09Postman collection10API changelog11Authentication12API key scopes13Freshness levels14Source confidence15Status monitoring16Rate limiting17Get countries18Get states19Get lotteries20Get lottery21Get schedules22Draw years23Lottery results24History export25Number frequency26Result checker27Error handling

Live API examples

Jump from the docs to real public pages that use the same read models.

Latest results browserSee the compact public result model with filters and draw dates.
Lottery catalogFind game names, states, ball counts, latest numbers, and API guides.
Maryland Pick 3 API guideOpen a concrete endpoint example using the same game shown in snippets.
Pricing and limitsCompare freshness targets, request limits, and integration features.
Customer integration centerSign in to check API keys, usage, webhook delivery, plan limits, and the next recommended action.
OpenAPI contractUse the machine-readable contract for code generation and integration tests.

Why source confidence exists

Lottery Feed API separates stored winning numbers from the evidence role behind those numbers. Public responses expose compact source-confidence labels while private collection diagnostics and review notes remain outside the customer contract.

Levels returned by the API

The same labels can appear in latest results, history rows, lottery catalog rows, statistics summaries, and result-check responses. Treat the level as an evidence role, not as a legal endorsement or lottery-operator partnership claim. Unknown-level rows can display Published source when a source name is recorded but the public confidence role is not classified yet.

{
  "source_confidence_levels": [
    {
      "level": "official",
      "label": "Official source",
      "policy": "The result is linked to a source that has been classified as the official lottery operator.",
      "public_meaning": "The source classification is supported by reviewed evidence for this source."
    },
    {
      "level": "verified",
      "label": "Verified source",
      "policy": "The result is linked to a reviewed independent source and carries an explicit verified classification.",
      "public_meaning": "The result has reviewed independent evidence but is not labelled as official."
    },
    {
      "level": "observer",
      "label": "Cross-checked source",
      "policy": "The result was observed through an independent comparison source.",
      "public_meaning": "Comparison evidence is informative and does not imply official-source confirmation."
    },
    {
      "level": "fallback",
      "label": "Fallback source",
      "policy": "The result was supplied by a reviewed fallback source.",
      "public_meaning": "Fallback evidence is identified separately from official-source confirmation."
    },
    {
      "level": "manual",
      "label": "Operator reviewed",
      "policy": "The stored result was reviewed or corrected by an authorized service operator.",
      "public_meaning": "A human review or correction is recorded for this result."
    },
    {
      "level": "unknown",
      "label": "Source verification pending",
      "label_variants": [
        "Source pending",
        "Published source"
      ],
      "policy": "The result is stored, but its source does not have sufficient customer-visible classification evidence.",
      "public_meaning": "Do not describe this result as official or verified."
    }
  ]
}

Recommended customer display

Show the human label near the draw date and numbers. For official and verified rows, a compact trust badge is appropriate. For observer, fallback, manual, or unknown rows, keep the label visible and avoid wording that implies the result came directly from the official lottery website unless your own downstream checks confirm that.

Customer decision table

Use this table when mapping source-confidence labels into a customer product. It keeps the public UI direct while preserving the operational distinction between official, verified, observer, fallback, manual, and unclassified rows. The table is generated from the same policy rows used by the public API code, so every visible label has a documented display decision and integration action.

{
  "source_confidence_display_decisions": [
    {
      "level": "official",
      "label": "Official source",
      "recommended_display": "Show as official-source data near the draw date and numbers.",
      "integration_action": "Accept for official-first integrations and still upsert by game_code plus draw_date.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    },
    {
      "level": "verified",
      "label": "Verified source",
      "recommended_display": "Show as verified feed data with the source-confidence label visible.",
      "integration_action": "Accept for most integrations that allow verified feed rows.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    },
    {
      "level": "observer",
      "label": "Cross-checked source",
      "recommended_display": "Show as observer evidence and avoid official-source wording.",
      "integration_action": "Use for comparison, speed checks, or customer display only when your policy allows observer rows.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    },
    {
      "level": "fallback",
      "label": "Fallback source",
      "recommended_display": "Show as approved fallback data and keep the fallback label visible.",
      "integration_action": "Accept only if your policy allows approved fallback rows while official access is unavailable.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    },
    {
      "level": "manual",
      "label": "Operator reviewed",
      "recommended_display": "Show as operator-reviewed or corrected data with correction context when present.",
      "integration_action": "Treat as a correction/update path and reconcile against previously stored numbers.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    },
    {
      "level": "unknown",
      "label": "Source verification pending",
      "recommended_display": "Show as published data with source review pending; do not imply official verification.",
      "integration_action": "Store the row if visible, but keep review pending in your own UI until confidence is upgraded.",
      "public_payload_boundary": "Use source_confidence, provenance, correction, and optional trust_evidence; do not wait for raw source logs in customer-facing systems."
    }
  ]
}

Provenance boundary

Public API responses include a compact provenance object next to source_confidence when a draw row is visible. It contains a customer-safe label, role, optional source display fields, and a short display sentence. Add include=trust when a customer UI needs the bounded public timeline with source role, observation time, and storage time.

{
  "source_confidence": {
    "level": "observer",
    "label": "Observer source",
    "policy": "Numbers came from an observer source used for speed, comparison, or mismatch detection."
  },
  "provenance": {
    "label": "Magayo",
    "role": "observer",
    "source": "magayo",
    "provider": "Magayo",
    "display": "Magayo observed this result for comparison."
  },
  "trust_evidence": {
    "summary": {
      "label": "Observer provenance",
      "headline": "Observer result for comparison"
    },
    "timeline": [
      {
        "label": "Source role",
        "value": "Observer source",
        "caption": "Numbers came from an observer source used for speed, comparison, or mismatch detection.",
        "status": "ready"
      },
      {
        "label": "Source observed",
        "value": "Jun 21, 2026, 12:00 PM UTC",
        "caption": "Magayo is the public source name in the compact feed.",
        "status": "ready"
      },
      {
        "label": "Result stored",
        "value": "Jun 21, 2026, 12:01 PM UTC",
        "caption": "Timestamp when Lottery Feed API stored this draw in the customer-visible feed.",
        "status": "ready"
      }
    ]
  }
}

Mismatch and correction behavior

When numbers are corrected, manually approved, or stored through observer or fallback evidence, the public confidence label can become Operator reviewed, Observer source, or Fallback source. Public detail pages and draw APIs can show compact correction evidence by default. Add include=mismatch_timeline only for reconciliation screens that need a bounded source-comparison timeline. Customer systems should store draw_date, game_code, numbers_string, source_confidence.level, provenance.role, correction.version_count, mismatch_timeline.summary.class, mismatch_timeline.review_state.state when requested, and inserted_at so they can detect and audit changes.

GET https://api.lotteryfeedapi.com/v1/results/latest/md-pick3-midday?include=trust,mismatch_timeline
{
  "game_code": "md-pick3-midday",
  "numbers_formatted": "2-3-6",
  "source_confidence": { "level": "verified", "label": "Verified source" },
  "mismatch_timeline": {
    "available": true,
    "stored_numbers_formatted": "2-3-6",
    "summary": {
      "class": "observer_disagreement",
      "label": "Observer disagreement",
      "decision": "Stored result kept after public review evidence"
    },
    "review_state": {
      "state": "operator_reviewed",
      "label": "Operator review completed",
      "public_note": "A reviewed correction or approval path is recorded for this result."
    },
    "events": [
      { "type": "stored_result", "label": "Stored public result", "source_role": "verified", "numbers_formatted": "2-3-6" },
      { "type": "observer_disagreed", "label": "Observer reported different numbers", "source_role": "observer", "numbers_formatted": "8-1-2" }
    ]
  }
}

Next: Status monitoring
Lottery Feed API

Normalized lottery draw results, history, schedules, source-confidence metadata, and descriptive analytics for integrations and personal analysis.

Independent software and data service. We do not sell lottery tickets, accept bets or player funds, operate draws, determine outcomes or pay prizes.Lottery names and trademarks belong to their respective owners. Lottery Feed API is an independent data service and is not affiliated with, endorsed by, sponsored by or operated by any lottery authority.
LotteriesDaily ArchiveCountriesStatesStatusResponsible UseAcceptable UseReport incorrect resultCompanyTermsPrivacyAccount