Stop scalping and ticket fraud with API-based verification

What TicketKing is

TicketKing is an API-first ticket verification and anti-abuse layer built for ticket merchants, event platforms, venues, promoters, marketplaces, and developers. It sits between your ticketing system and the gate.

• Merchants issue secure tickets via API; each ticket can be bound to rules (transfer, resale, activation window).
• Venues validate tickets quickly at entry using proof-based verification—no need to see full identity or order data.
• Event operators define transfer, access, resale, and verification rules; TicketKing enforces them at issuance and at the gate.
• Privacy: tickets can be verified without exposing unnecessary personal data. Zero-knowledge ticket verification proves entitlement without oversharing.

You integrate with an API key. No heavyweight SDK or lock-in; you keep control over your merchant flow, venue flow, and resale rules.

The problems it solves

Ticket fraud prevention and ticket scalping prevention require addressing real market failure points. TicketKing targets these directly:

Why static QR tickets fail for high-demand events

Static QR codes are a single string: anyone with a screenshot or print can reuse them. For high-demand events, that leads to duplicate entry, fake tickets, and scalpers selling the same code many times. Static tickets also give no way to revoke or time-limit validity without reissuing the whole ticket. TicketKing replaces the static code with a dynamic proof token: short-lived, one-time-use, and bound to your eligibility and rules. The QR still looks like a QR, but what’s inside is a cryptographic proof that expires and is consumed on first successful scan—so screenshot and replay attacks fail.

Static QR tickets vs account-bound tickets vs TicketKing proof-based tickets

How buyers evaluate alternatives: a clear comparison helps both search and conversion.

How TicketKing reduces scalping

Ticket scalping prevention is achieved through controls that merchants configure—not magic. TicketKing provides the infrastructure; you set the rules.

• Wallet or buyer binding: optionally bind a ticket to a wallet or account so only that holder can request a valid proof token.
• One-ticket-one-holder logic: each proof token is issued for a single ticket and consumed on first successful gate verify.
• Controlled transfer rules: allow or block transfers; require approval or re-issuance so that only compliant transfers get valid proofs.
• Delayed activation windows: tickets can become valid only from a certain time (e.g. 24h before event), reducing speculative hoarding.
• Proof-based validation at entry: the gate calls the verify API; only a valid, unconsumed proof passes.
• Dynamic QR validity: the QR encodes a short-lived token (e.g. 5–60 seconds); it rotates, so screenshots expire.
• Replay resistance / duplicate scan protection: first successful verify consumes the token; subsequent scans are rejected.
• Issuance limits and programmable restrictions: you can rate-limit or scope proof issuance by event, ticket type, or buyer.
• Rule-based transfer approval: integrate with your transfer workflow so that only approved transfers receive proof eligibility.
• Merchant-defined resale constraints: resale can be disabled, or allowed only through your channel, with proof re-issued only for compliant resales.

How ZK QR code tickets work

Zero-knowledge ticket verification and ZK QR code tickets sound technical but the flow is straightforward.

1. Ticket issued via API: the ticket merchant (or your backend) calls the TicketKing API with a ticket identifier and optional rules. Eligibility is checked (e.g. paid, not cancelled, within transfer rules).
2. QR contains or references a cryptographic proof: the API returns a short-lived token (e.g. JWT or proof reference). Your app encodes that into the QR code the attendee sees. The QR does not contain raw personal data; it contains a proof that “this ticket is valid right now.”
3. Verifier checks validity and status: at the gate, the scanner sends the token to the verify endpoint. The API checks signature, expiry, and whether the token has already been consumed.
4. Minimal data exposure: the ticket can be validated without exposing identity or full order details. The verifier learns only “valid, one entry” or “invalid.”
5. Stronger anti-fraud logic: because the proof is time-bound and one-time-use, verification supports stronger anti-fraud behaviour than static QR tickets—no reuse, no screenshot validity.

Implementation guide

Integrate TicketKing with an API key. Typical flow:

1. Create API key: obtain an API key (e.g. X-AffixIO-Key or Bearer) from AffixIO. Use it for all TicketKing requests.
2. Issue ticket: when a customer completes purchase, your backend registers the ticket as eligible (in your system or via TicketKing eligibility). The ticket_id is what you will pass when requesting a proof token.
3. Generate ZK QR code: when the holder opens the ticket (e.g. in your app), your backend calls POST /api/ticketking/proof-token with ticket_id and optional ttl_seconds. You receive a token; encode it into the QR (and optionally refresh it every few seconds for revolving display).
4. Attach ticket rules: transfer, resale, and activation rules are enforced at proof-token issuance. Only eligible tickets (per your rules) receive a token.
5. Verify at gate: the gate scanner or your venue app calls POST /api/ticketking/verify with the token from the QR. If valid and not yet consumed, the API returns success and consumes the token; your system grants entry. If expired or already used, the API returns an error.
6. Transfers / revocations / revalidation: when a ticket is transferred or revoked, update eligibility so that the old holder no longer receives a valid proof token. Revalidation after transfer can issue a new proof to the new holder once your rules allow it.

Sample endpoints

Real TicketKing endpoints (base URL https://api.affix-io.com; use your API key in production).

Issue a proof token (ticket merchant or app backend)

Request a short-lived proof token for a ticket. Use this to generate or refresh the QR payload. Business meaning: “Give me a valid proof for this ticket_id so the holder can show it at the gate.”

curl -X POST https://api.affix-io.com/v1/api/ticketking/proof-token \
  -H "X-AffixIO-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ticket_id":"TKT-abc123","ttl_seconds":60}'

{
  "token": "eyJhbGciOiJIUzI1NiIs...",
  "expires_at": "2025-03-10T12:05:00.000Z",
  "ticket_id": "TKT-abc123",
  "circuit_id": "ticketing",
  "eligible": true
}

Encode the token value into the QR code. Optionally call again before expiry to refresh (revolving QR).

Verify and consume at gate (venue / scanner)

Send the token from the scanned QR. First successful call consumes the token and returns accepted; subsequent calls for the same token return “already_consumed.” Business meaning: “Validate this attendee’s proof and allow one entry.”

curl -X POST https://api.affix-io.com/v1/api/ticketking/verify \
  -H "X-AffixIO-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"token":"eyJhbGciOiJIUzI1NiIs...","gate_id":"GATE-A1"}'

{
  "accepted": true,
  "ticket_id": "TKT-abc123",
  "consumed_at": "2025-03-10T12:04:35.000Z",
  "gate_id": "GATE-A1"
}

{
  "accepted": false,
  "reason": "already_consumed"
}

Get ticketing circuit (discovery)

Returns the ticketing circuit definition (id, name, sector, input methods). Useful for developers and dashboards.

curl -s https://api.affix-io.com/v1/api/ticketking/circuit \
  -H "X-AffixIO-Key: YOUR_API_KEY"

Why merchants implement it

• Reduce fraud losses: fewer fake or duplicated tickets, fewer chargebacks and disputes.
• Reduce scalper pressure: proof-based, one-time-use tickets and optional binding make bulk resale and screenshot resale less viable.
• Protect fan trust: fans know that a TicketKing-verified ticket is legitimate and that duplicate scans are blocked.
• Improve gate confidence: venue staff get a clear accept/reject; no ambiguity from static or copied codes.
• Enforce resale and transfer policy: you define rules; the API enforces them at issuance and entry.
• Keep control over business rules: you remain the ticket merchant; TicketKing is the verification layer.
• Avoid unnecessary PII exposure: zero-knowledge ticket verification means the gate does not need to see identity or order data.
• Support premium and high-demand events: scalable, API-first integration fits concerts, festivals, sports, and high-volume entry.
• Work across web, app, and venue operations: same API for issuance (web/app) and verification (gate/scanner/app).

Use cases

Why AffixIO

TicketKing runs on AffixIO infrastructure. AffixIO provides privacy-first verification, programmable trust, and secure proofs via an API-first deployment. We do not store PII; we return binary eligibility and proof tokens. TicketKing is the ticketing application of that layer: you get anti-scalping and ticket fraud prevention without handing over your data or losing control. For technical details, see Technical architecture and Eligibility verification API. For compliance and privacy, see Privacy.

FAQ

Common questions about ticket scalping prevention, ticket fraud prevention, and TicketKing.