Sandbox Fixtures
Use deterministic lf_sandbox_* API responses for SDK tests, CI smoke checks, and integration wiring without touching live lottery feed data.
Section
04 / 27
Live API examples
Jump from the docs to real public pages that use the same read models.
Endpoints
/v1/results/latestDeterministic latest result fixtures for API clients.
/v1/results/historyDate-filtered fixture history with stable draw payloads.
/v1/lotteriesCatalog read model backed by fixture data when using lf_sandbox_* keys or the documented legacy demo token.
/v1/statusFixture quality/status summary for smoke checks.
When to use sandbox keys
Reserved lf_sandbox_* bearer tokens are accepted only while public sandbox access is enabled. The exact lf_test_demo_sandbox token remains a legacy compatibility credential; other lf_test_* values use normal API-key authentication. Sandbox requests are intended for SDK onboarding, CI smoke tests, contract tests, demos, and webhook or importer wiring where the caller needs stable data instead of live draw timing.
curl -sS "https://api.lotteryfeedapi.com/v1/results/latest?state=MD&ball_count=3&short=1&limit=25" \ -H "Accept: application/json" \ -H "Authorization: Bearer lf_test_demo_sandbox" \ -i
What the response proves
Sandbox fixtures exercise the same public /v1 read-model shape customers use in production: state-grouped lottery rows, draw_date, numbers, numbers_formatted, numbers_string, source confidence fields, links, and schedule metadata. They do not prove live source freshness or customer entitlements.
HTTP/2 200
x-api-sandbox: true
x-lottery-feed-access: sandbox
content-type: application/json
{
"date": "2026-06-21",
"state_count": 3,
"lottery_count": 4,
"states": [
{
"code": "MD",
"name": "Maryland",
"lotteries": [
{
"game_code": "md-pick3-midday",
"display_name": "Maryland Pick 3 Midday",
"ball_count": 3,
"latest_draw": {
"draw_date": "2026-06-21",
"numbers": ["2", "3", "6"],
"numbers_formatted": "2-3-6",
"numbers_string": "2-3-6",
"source": "sandbox-fixture",
"status": "sandbox sample"
}
}
]
}
]
}Endpoints covered by fixtures
Sandbox access currently covers the public read endpoints that are safest for automated tests: latest results, date-filtered history, status or quality summaries, draw years, lottery catalog, and schedule-backed read models. Use live lf_live_* keys when you need real customer data, billing limits, scopes, and freshness behavior.
GET /v1/results/latest?state=MD&ball_count=3&short=1&limit=25 GET /v1/results/history?date=2026-06-21&state=MD GET /v1/lotteries?state=MD GET /v1/schedules?state=MD GET /v1/status GET /v1/results/years?game_code=md-pick3-midday
Stable fixture manifest
Treat the fixture set as a small contract pack, not as a sample of today's feed. The default sandbox pack contains Maryland Pick 3 Midday, Maryland Pick 4 Midday, Texas Pick 3 Day, and Florida Pick 5 Midday on draw date 2026-06-21. Keep tests pinned to game_code, draw_date, ball_count, numbers_formatted, and the sandbox headers so CI fails only when the public contract intentionally changes.
{
"sandbox_fixture_manifest": {
"credential_prefix": "lf_sandbox_",
"generated_at": "2026-06-21T12:00:00.000Z",
"draw_date": "2026-06-21",
"games": [
{ "game_code": "md-pick3-midday", "state": "MD", "ball_count": 3, "numbers_formatted": "2-3-6" },
{ "game_code": "md-pick4-midday", "state": "MD", "ball_count": 4, "numbers_formatted": "1-4-9-4" },
{ "game_code": "tx-pick3-day", "state": "TX", "ball_count": 3, "numbers_formatted": "1-7-1" },
{ "game_code": "fl-pick5-midday", "state": "FL", "ball_count": 5, "numbers_formatted": "2-5-4-4-5" }
],
"production_usage_counted": false,
"live_feed_read": false
}
}CI contract test
Keep the assertion small and stable. Check the API envelope, one known fixture row, numbers_formatted, and the sandbox response headers. Do not assert current production draw dates from CI because official source publication timing changes by lottery.
const response = await fetch('https://api.lotteryfeedapi.com/v1/results/latest?state=MD&ball_count=3&short=1&limit=25', {
headers: {
accept: 'application/json',
authorization: 'Bearer lf_test_demo_sandbox'
}
});
if (!response.ok) throw new Error(`Sandbox API failed: ${response.status}`);
if (response.headers.get('x-lottery-feed-access') !== 'sandbox') {
throw new Error('Expected sandbox access header.');
}
const payload = await response.json();
const maryland = payload.states?.find((state) => state.code === 'MD');
const pick3 = maryland?.lotteries?.find((lottery) => lottery.game_code === 'md-pick3-midday');
if (pick3?.latest_draw?.numbers_formatted !== '2-3-6') {
throw new Error('Sandbox fixture contract changed.');
}Production boundary
Sandbox requests do not read the live feed, do not count as production usage, do not validate paid entitlements, and do not represent official draw freshness. They are a deterministic contract surface only. Production workers, customer backends, and billing-sensitive jobs should use issued lf_live_* keys.
API documentation FAQ
Short answers for teams using sandbox fixtures in production integrations.
Can sandbox keys be used in production?
No. Use lf_sandbox_* keys only for deterministic integration checks. Production services should use issued lf_live_* keys so scopes, limits, usage accounting, and customer freshness policy apply.
Do sandbox requests count against daily API limits?
No. Sandbox requests do not count as production usage. They use a separate bounded abuse limit.
Are sandbox results live lottery results?
No. They are fixed fixtures. Use them to validate code paths, not to display current customer-facing results.
Next: SDK starter