Model owners
The write lane
Enrol a model, commit predictions before each event, reveal after settlement. The model itself is never transmitted. What leaves your infrastructure is a hash before the event and a settled prediction after it.
Integration — submit a model, or read the registry
Two lanes.Submit a model, or query the registry.
One programmatic surface with two directions. Model owners commit predictions before their events; buyers read the scored records that come out the other side. Both run on the same ledger, and neither requires trusting us about what the other did.
Live
Anchored530
Models in prod16
LedgerPublic
§ 01Who integrates
Two sides, one surface.
The write lane and the read lane serve different parties with opposite interests. That is the point — a record only means something when the party producing it and the party consuming it are not the same.
Desks, funds, and integrity vendors
The read lane
Query scored records in one format across every enrolled model, including the ones that failed. Re-derive any figure yourself from the published artifacts — the API is a convenience, not the source of truth.
§ 02What you integrate with
Three live products. One audited engine.
An integrator gets contract-bound access to the same three products the terminal runs on — every one of them with a public proof surface a CTO can verify before any commercial conversation.
SplitWinner
The production prediction engine. Per-sport models, conformally calibrated, conformity-evaluated against held-out outcomes. Live performance refreshed hourly; every retrain ships its full held-out metric panel — ROC-AUC, F1, MCC, accuracy — into the public audit_models ledger.
See the engineeringThe public audit ledger
During the alpha, every prediction was cryptographically anchored to a public, immutable ledger before kickoff — the record is sealed; the official chain continues it. SHA-256 content hashes daily; OpenTimestamps proof upgraded to a Bitcoin Merkle-path attestation. Append-only at the database level — UPDATE and DELETE rejected by trigger. Clone the repo, run verify.py against any sample, check the math yourself.
See the auditSplitWinnerGPT
A purpose-built LLM grounded in the audited pipeline. Ask it why a model called a game the way it did, which prior anchored row supports the answer, how a sport has been trending — every numerical claim cites the exact audit_trail entry it was computed from. The same prediction provenance the rest of the stack carries, in natural language.
Preview SplitWinnerGPT§ 03Access
Two lanes, one surface.
Model owners commit predictions before their events. Buyers read the scored records that come out the other side. Same ledger, same protocol, opposite directions.
Enrolment
Open
- Access
- Register a model and mint credentials
- Data
- Your model never leaves your infrastructure
- Rate
- —
- Purpose
- Get a model into the registry and read the standard it will be scored against.
Ingest
Commit & reveal
- Access
- Commit before the event, reveal after settlement
- Data
- Hashes in, settled predictions after
- Rate
- —
- Purpose
- The write lane. Hashes before the event, settled predictions after — the model itself never moves.
Registry read
Scored records
- Access
- Scored records in one format
- Data
- Passes and failures alike
- Rate
- —
- Purpose
- The read lane. Every figure re-derivable from the published artifacts.
Nothing is metered by prediction volume. A record costs what it costs to score, not what the signal is worth.
The protocol
We hold digests. Never picks.
Predictions are hashed and anchored before their events and revealed only after settlement. By the time a pick is readable here it is already history, so we cannot act on what we are validating — and that is a property you can verify rather than a promise you have to accept.
§ 04Access model
One credential per request. Two lanes.
Every /v1/* call authenticates with a per-tenant bearer token. Sandbox tokens reach the mock layer; enterprise tokens reach the real data after the request signing + rate-limit middleware. Our first-party clients additionally sign every request; B2B integrators don't (their credentials aren't extractable from a public bundle, so the additional layer would buy nothing). One credential per enterprise client — rotation is revoke-then-mint, never concurrent, matching the single-credential pull-and-cache contract.
- Bearer authentication
- Authorization: Bearer swk_b2b_<env>_<random>. Issued per integrator, hashed at rest, rotatable from the portal. A revoked key stops working on the next request.
- Sandbox and enterprise
- Sandbox is self-serve and free for integration evaluation. Enterprise is issued by contract — pull-and-cache, you serve your end users from your own stack. No middle tiers.
- Kalshi: bring your own account
- /v1/kalshi/match and /v1/kalshi/markets return matched tickers + metadata; we never proxy live Kalshi prices to enterprise customers. Take the ticker IDs we return and fetch live prices from api.elections.kalshi.com directly with your own Kalshi credentials. Your audit trail, your rate-limit posture, your compliance scope. /v1/kalshi/market-prices and /v1/kalshi/candlesticks return 410 Gone at enterprise.
- Rate posture
- Per-key rate limits, sized to tier. X-RateLimit-Limit / -Remaining / -Reset on every response. 429 returns problem+json with Retry-After. Surge bursting is not promised at any tier — sustained rate is.
- Stable error contract
- RFC 7807 problem+json everywhere. A stable code field per error class (rate_limited, insufficient_tier, invalid_credentials, ...). Branchable in a client without parsing prose.
§ 05API surface
Nine endpoint groups.
What's available today, at a glance. Full reference in the public OpenAPI spec — every route, every schema, every error code.
/v1/quant
Models, calibration drift, conformal coverage, season calendar, performance — the methodology-page payload.
GET /v1/quant.live.performance.aggregate → win rate, Brier, ECE, n
/v1/audit
Immutable prediction ledger — summary, recent receipts, per-anchor detail, operational pulse.
GET /v1/audit/recent?limit=10 → last 10 receipts with content hashes
/v1/predictions
Today's slate, per-pick intel, per-pick model — the full prediction surface, available under contract.
GET /v1/predictions/today → slate (full-signal fields redacted off-contract)
/v1/insights
Nineteen analyser surfaces — team form, sport-specific edges, model performance breakdowns.
GET /v1/insights/:sport → 19-dimension per-sport analyser output
/v1/engineering
CI signal for the api repo — test count, coverage, lint/typecheck/audit booleans, last passing build.
GET /v1/engineering → test_count, coverage_pct, last_passing_sha
/v1/config
Public operational invariants — sports-day rollover, disclosure window.
GET /v1/config → sports_day_rollover_et, disclosure_window_days
/v1/incidents
Disclosed operational incidents under the 7-day disclosure protocol.
GET /v1/incidents → disclosed incidents, ordered most-recent first
/v1/training
Recent model registrations from the immutable audit_models ledger.
GET /v1/training/recent?limit=10 → last 10 model registrations
/v1/kalshi
Predictions ⇄ Kalshi market matching: tickers, sub-titles, series config. Enterprise customers fetch live prices from Kalshi directly with their own credentials — we do the matching, you do the trading.
GET /v1/kalshi/match → ticker IDs (prices stripped at enterprise)
The OpenAPI 3.1 spec is the contract of record. Every route, every Zod-validated request and response shape, every error code. Browse the rendered reference at splitwinner.com/docs, or grab the raw JSON straight from api.splitwinner.com/openapi.json — they're the same source, refreshed live from the api.
§ 06Example response
What an integrator sees.
One row from /v1/audit/recent. Cryptographic receipt only — the prediction value is redacted on the live feed and revealed via /v1/audit/settled after the game grades.
v1/audit/recent.json
GET /v1/audit/recent?limit=1
{
"data": [
{
"id": "5a31a8e2-7c4f-4b9d-9e21-a3f8c0d2e1b4",
"ml_prediction_id": "8b2c-1f3a-49d8-…",
"content_hash": "sha256:abc123def456789…",
"short_hash": "abc123def4567890",
"recorded_at": "2026-06-11T08:00:00Z",
"original_created_at": "2026-06-11T05:14:32Z",
"game_time": "2026-06-11T19:00:00Z",
"passed_conformal": true,
"prediction_mode": "live",
"conformal_set_size": 1,
"model_id": "2025_2026_nfl_ml_1",
"lead_seconds": 49520,
"called_before_kickoff": true
}
],
"count": 1
}Bearer authentication on every /v1/* request. Full schema + every other route in the OpenAPI spec.
§ 07SLA + status
What we commit to.
Published commitments, contract floors, and the live pulse when the ledger is anchoring. No green dashboard theater — when the pipeline is paused, nothing here pretends otherwise.
Uptime
99.5%
Measured monthly · contract floor
p95 latency
< 500 ms
Prediction endpoints · over rolling 30 days
Drop cadence
Daily, pre-game
Published before each day's first kickoff while the pipeline runs
Pre-launch revenue. No public customer references yet — the live pulse above is the operational record. References available after first call under NDA.
§ 08Verify before buying
Run the proof without a contract.
Three steps. No account. No NDA. The verifier is plain Python — what your security team would run against the production feed, except they can run it now against the public ledger.
01
Read the contract
curl https://api.splitwinner.com/openapi.json
02
Clone the public ledger
git clone https://github.com/SplitWinner/audit_trail_alpha
03
Run the verifier
cd audit_trail && python verify.py content --predictions sample/predictions_full.json
What you would verify under contract, same code, today.
Verifier works on your machine. Ready to talk pricing and SLA?
Talk to enterprise§ 09How access works
Two paths in.
Sandbox path
01
Sign up
Email + Supabase Auth. No credit card. No NDA. No call.
02
Create a sandbox client
One click in the portal. Mint a key. Copy it once — we never store the raw value.
03
Build
Hit any /v1/* endpoint at api.splitwinner.com with Authorization: Bearer <key>. Plausibly-live mocked responses across the full surface — every endpoint, every field, every error code, 10 rpm.
Contract path (enterprise)
01
Apply
Submit the application form in the portal: company, use case, intended tier, expected monthly volume. Founder-led review within the business week.
02
NDA (if needed)
Mutual NDA to share pricing, SLA, support tier, reference customers. Same week, digital signature.
03
Contract
MSA, DPA, AUP, and a custom SLA template. Term length, support tier, and integration scope sized to the use case. ACH or wire — no card, no payment processor.
04
Onboarding
Paid-tier key issued by ops. Sandbox-equivalent walkthrough with the team that built the api. White-glove from day one.
What it costs
Annual enterprise contracts. Pricing reflects coverage scope, support intensity, and response SLA. The floor is institutional-grade, not indie — if your integration runs on a single engineer's credit card, the sandbox is the right lane and enterprise is not. Specifics under NDA.
Research-only and regulator engagements get a lighter conversation shape — say so in the application.
How we bill
Direct invoice, ACH or wire, against the signed contract. No payment processor, no merchant-of-record, no card fees, no platform fees inflating your invoice. We don't carry chargeback risk, you don't carry vendor-counterparty risk.
§ 10Questions
What an integrator asks first.
The five questions that show up before any other commercial conversation.
What does the API actually deliver today?
Daily, pre-game predictions in JSON, published each morning before kickoff while the pipeline runs. v1 cadence is locked at daily — game-level predictions, not real-time, not in-game.
What sports and markets are covered?
Game-level only. Moneyline today, two spread models in production, more spread models adding next, totals on the roadmap. No player props, no in-game, no DFS in v1.
How do I integrate? What's the contract surface?
Versioned /v1/* surface, Bearer API key plus HMAC-signed requests, RFC 7807 problem+json errors, X-RateLimit-* headers, OpenAPI spec as the contract. The public verifier is part of the contract, not an extra.
Can I verify the predictions came from when you claim?
Yes. Every prediction carries an audit_trail row id and a content hash. Clone github.com/SplitWinner/audit_trail_alpha, run verify.py against the day in question, check the GitHub commit timestamp. Three steps, no special tooling, no contact with us required.
Run the verifier yourselfWhat's the uptime / SLA?
v1: 99.5% uptime, p95 latency under 500 ms on prediction endpoints.
Two ways to start.
Sandbox in five minutes via the developer portal, or apply for enterprise access and hear from the team that built the api within the business week.