Security at ParlayAPI

How we secure customer data, how we handle disclosures, what our infrastructure looks like, and what we expect from integrators. If you're evaluating ParlayAPI for an enterprise contract, this page is the answer to "what does your security program look like" in writing.

Disclosure policy (RFC 9116)

Vulnerability reports come through the canonical /.well-known/security.txt file. The summary:

We commit to acknowledging vulnerability reports within 24 hours and providing a remediation timeline within 72 hours. No bounty program today; we'll credit researchers publicly with their consent.

Data we handle

The data flowing through ParlayAPI is intentionally limited.

• Sportsbook odds data: public-page-only. The same prices any visitor to the bookmaker's website sees. Not customer data; not user-identified.
• Customer bet records (CLV grading): the bets you POST to /v1/clv/history. Stored only as long as needed to grade and return the response (typically <5 seconds); not persisted to durable storage. Memory caches are flushed on worker restart.
• Account data: email address, optional company name, billing details (Stripe handles card data directly; we never see card numbers).
• Request logs: 30 days of (request_id, endpoint, status, duration, api_key_id) tuples. No request bodies, no response bodies.

No PII is collected from the betting public. We don't run user identification, KYC, or geolocation services. The only personally-identifying data we hold is what an integrator volunteers when they sign up (email, optional name).

Authentication and key handling

• API keys are 32-byte random secrets. Treat them as bearer credentials.
• Pass via X-API-Key header (preferred) or ?apiKey= query parameter.
• Keys can be revoked instantly from the dashboard. Revoked keys return 401 on all subsequent requests within ~5 seconds (Redis-backed allowlist).
• Unlimited keys per account. Use a separate key per environment (prod / staging / dev) so a leak in one doesn't compromise the others.
• We never log key values. Request logs reference the key by its 8-character ID prefix only.

Transport security

• TLS 1.2+ only. TLS 1.0 and 1.1 disabled at the gateway. SSL Labs grade A+.
• HSTS with max-age=31536000; includeSubDomains; preload.
• Certificates managed by Let's Encrypt, rotated automatically every 60 days.
• OCSP stapling enabled.
• HTTP/2 enabled on all /v1/* routes.

Webhook security

Every webhook delivery (prop-line alerts, source-quality alerts, bet-settled notifications) is signed with HMAC-SHA256. Verify the signature before trusting the payload.

X-Parlay-Signature: t=1779000000,v1=8a4f...

# Verification (Python):
import hmac, hashlib
def verify(body_bytes, header, secret):
    t = header.split("t=")[1].split(",")[0]
    v1 = header.split("v1=")[1]
    expected = hmac.new(secret.encode(),
                        f"{t}.{body_bytes.decode()}".encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, v1)

Reject deliveries with timestamps outside a ±5 minute skew. Use a relay if you need to fan out to Slack/Discord; reference implementations at /built-with.

Infrastructure

• Primary data tier runs on dedicated hardware behind a documented public gateway. Failover thin-tier on a separate cloud host. Both have public health endpoints (/v1/status) you can monitor.
• Postgres is the system of record. Backed up daily; tested-restore procedures.
• Redis used for caching and coordinator state only. No durable customer data.
• Multi-node ingest mesh details documented at our architecture blog. Nodes only sign and forward; they don't have direct database access.
• Operator-facing dashboards (/dashboard/admin/*) require a separate admin session cookie, not the public API key.

Operational practices

• Public changelog: /changelog updates within minutes of every deploy, including security-related fixes.
• Post-mortems: incidents that affect customer traffic get a public runbook within 48 hours. Recent example: 2026-05-19 gateway 502 outage.
• Secret scanning: pre-commit hook in our repo blocks DigitalOcean tokens, AWS keys, GitHub PATs, Slack bot tokens, Stripe live keys, Anthropic API keys, GCP service account JSON, and JWT-shaped bearer tokens before they can land in git.
• Legal scope: internal policy at docs/LEGAL_SCOPE.md binding. Authenticated sportsbook paths, credential-gated DFS apps, and anything that violates a bookmaker's TOS are permanently quarantined. We don't deploy them even when the code exists.
• No synthesis rule: if a book only quotes one side of a prop, we return the other side as null. We never fabricate prices. Audit hooks enforce this; the rule is referenced throughout our source code with explicit "memory rule compliance" comments.

What we expect from integrators

• Never commit API keys to public repos. Use environment variables or a secret manager.
• Rotate keys quarterly or after any suspected exposure. The dashboard supports rotation with a 24h overlap window.
• Verify webhook signatures before processing payloads.
• Use a separate key per environment.
• If your integration is exposed to end users (e.g. a betting app you sell), proxy our API through your backend so your customers never see the key.

What we don't do

• We don't sell or share customer data. Email lists, request logs, integration patterns: none of it leaves our systems.
• We don't run third-party analytics with user-identifying signals on documentation pages or the dashboard.
• We don't ingest authenticated sportsbook paths. Pinnacle's authenticated WebSocket, Pick6's logged-in DFS surface, anything credential-gated: permanently quarantined per legal scope.
• We don't synthesize prices. One-sided props return null, not an estimate.

Reporting a vulnerability

Email support@parlay-api.com with subject prefix [SECURITY]. Include reproduction steps, expected vs actual behavior, and any PoC code. We acknowledge within 24 hours and ship a remediation timeline within 72 hours. We'll credit the researcher publicly in the next changelog entry once a fix ships, unless they prefer anonymity.