Skip to content
All legal documents

API Privacy Policy

How we handle data for SplitWinner API customers.

Version 1 · Effective June 13, 2026

SplitWinner API Privacy Policy

Last updated: June 2026

This policy describes how SplitWinner LLC ("SplitWinner", "we", "us") collects, uses, and protects data in connection with the SplitWinner API at api.splitwinner.com. It applies to enterprise and sandbox API customers.

For consumer mobile app data handling, see the App Privacy Policy. For marketing-site and developer-portal data handling, see the Website Privacy Policy.

We are based in the State of Texas, United States.

1. The minimum, by design

The API is a B2B data service. We collect the minimum needed to authenticate customers, meter usage, prevent abuse, fulfill the Master Services Agreement, and comply with law. We do not run ads, profiles, or behavioral surveillance against API customers. We do not hold customer Kalshi credentials, and we are not in the path of any Kalshi order placed by a customer.

2. Data we collect from API customers

Account and application

When you create a developer-portal account or apply for an enterprise tier, we collect what's documented in the Website Privacy Policy — including your sign-in identity (via Supabase Auth) and the enterprise application form fields (company, applicant, use case, jurisdictions, budget, timeline).

This data is used to evaluate your application, sign the appropriate Master Services Agreement, and provision the customer record.

API client and key metadata

When you create an API client and mint API keys, we store:

  • Client record (api_clients): customer tenant identifier, the owning developer-portal account, the team handle you chose, the tier (sandbox or enterprise), the client status, an internal contract reference (for enterprise), and a monthly request quota.
  • Key record (api_keys): the first 16 characters of the key (for display in the dashboard); a SHA-256 hash of the full key (for authentication and revocation); optional restrictions you set, including CIDR allowlist and expiration date. We do not store the raw key value. It is shown to you once at creation; after that, only you have it.

Usage metadata

When you call the API, we record per-request metadata for metering, abuse prevention, and billing:

  • Timestamp
  • Endpoint path
  • Response status code and byte size
  • Request IP (used for CIDR allowlist enforcement and abuse detection)
  • The hashed key identifier (so we can attribute usage and apply rate limits, never the raw key)
  • The signed-request canonical inputs (method, path, body length, timestamp) are verified to validate request signing; we do not persist the raw request body beyond what is needed for support and abuse review.

Customer-supplied data

Customers must not transmit personal data of their end users through the API. The API is not designed to accept end-user PII. If a Customer transmits such data in violation of this policy or the API Terms, the Customer is the controller of that data and remains responsible for any obligations attaching to it. If a Customer requires PII transmission for a legitimate integration purpose, a signed Data Processing Addendum is required.

What we do NOT receive or store

  • Customer Kalshi credentials. Enterprise customers connect to Kalshi from their own infrastructure with their own credentials. We never receive a Kalshi API Key ID or RSA private key. We do not sign Kalshi requests. We do not proxy Kalshi prices. The customer's Kalshi audit trail stays on Kalshi.com.
  • Customer end-user PII (unless transmitted in breach of the API Terms, as above).
  • Card-on-file payment data. Enterprise customers invoice via ACH or wire under contract; there is no payment processor in the path.

3. How we use this data

  • Authenticate API requests and enforce per-key restrictions
  • Meter usage for billing and rate limiting
  • Detect and prevent abuse, fraud, key compromise, and policy violations
  • Operate the developer portal and customer dashboard
  • Fulfill the Master Services Agreement
  • Provide customer support
  • Comply with applicable law

4. Processors and subprocessors

ServicePurposeWhat they receive
VercelHosting and CDN for api.splitwinner.comAPI requests at the edge
SupabaseDatabase and authentication backboneCustomer records, key metadata, usage events
Upstash RedisRate-limit and short-term KV stateHashed key + window counters
SentryError reportingStack traces; no request/response bodies
BetterStackLog drainage and uptime monitoringAPI logs (request metadata, not bodies)

Each subprocessor operates under its own privacy policy and security standards.

5. Retention

CategoryRetention
API client and key metadataLifetime of the client; revoked keys retained for audit
Usage eventsRolling window for metering and abuse review; long-term aggregates retained
Application form dataWhile the customer relationship is active and for a reasonable period after
Logs (BetterStack)Per ingest configuration (typically short, days to weeks)
Sentry errorsPer project retention

Specific retention periods may be agreed in the Master Services Agreement.

6. Customer rights

The account-holder for an API customer may at any time:

  • Access the data we hold about the customer record and key metadata
  • Correct inaccurate data
  • Delete the account and customer record (subject to legal and audit retention)
  • Rotate or revoke API keys via the developer portal
  • Export usage data via the dashboard

Email legal@splitwinner.com to exercise any of these. We will verify identity and respond within 30 days.

7. Confidentiality

Non-public information you observe while integrating — including undocumented error patterns, internal identifiers visible in error payloads, rate-limit-bucket behavior, and infrastructure details — is Confidential Information under the API Terms §4. Do not publicly disclose it.

8. Security

  • All API traffic is encrypted via TLS.
  • API keys are stored as SHA-256 hashes; raw values are never persisted.
  • Production keys can be restricted by IP allowlist and expiration date. We recommend enabling both for any non-development key.
  • Customer Kalshi credentials never reach our infrastructure (see §2).
  • We invite responsible security research under our Security Disclosure.

9. Breach notification

If we confirm a breach that compromises a customer's personal data, we will notify the affected customer's billing contact via email within 72 hours of confirmation, unless law enforcement requests a delay. We will describe the nature of the breach, the data affected, and recommended next steps. Specific breach-notification SLAs may be tightened or extended under a Master Services Agreement.

10. Data Processing Addendum

A signed Data Processing Addendum (DPA) is available on request from customers who require one. Email legal@splitwinner.com to request a DPA.

11. International customers

The API is operated from the United States. Customers outside the United States may use the API to the extent permitted by their local law; data is processed in the United States.

12. Changes to this policy

We may update this policy. Material changes will be notified to active customers via email. Continued use of the API after a change constitutes acceptance.

13. Contact