The Ticket Fairy Authentication

generated: '2026-08-13'
method: derived
source: >-
  tf-checkout-react-native@1.0.47 (npm, published by the `theticketfairy` npm account) —
  src/api/Constants.ts and src/api/ApiClient.ts; corroborated by live CORS preflight on
  https://www.ticketfairy.com/api/v1/cart/ (2026-08-13)
note: >-
  DERIVED, NOT PUBLISHED. The Ticket Fairy publishes no authentication documentation, no developer
  portal and no OpenAPI. Everything below is read out of the company's OWN first-party client
  library on npm and confirmed against the live API's CORS preflight, which enumerates exactly
  which Authorization headers the origin accepts. No credential values are reproduced here: the
  React Native library ships a hard-coded checkout client_id/client_secret pair in
  src/api/Constants.ts, which is itself a finding (a shared public client secret shipped inside a
  distributed mobile bundle) but is not repeated in this artifact.
api: The Ticket Fairy REST API
base_url: https://www.ticketfairy.com/api
schemes:
- id: oauth2
  type: oauth2
  status: observed
  token_endpoint: https://www.ticketfairy.com/api/v1/oauth/access_token
  authorize_endpoint: https://www.ticketfairy.com/api/v1/oauth/authorize-rn
  register_endpoint: https://www.ticketfairy.com/api/v1/oauth/register-rn
  password_reset_endpoint: https://www.ticketfairy.com/api/v1/oauth/restore-password-rn
  token_type: Bearer
  header: 'Authorization: Bearer <access_token>'
  returns:
  - access_token
  - refresh_token
  - token_type
  - scope
  refresh: >-
    The token response carries a refresh_token and the client persists it; there is no published
    refresh endpoint or token lifetime. Rotation semantics are undocumented.
  scopes_documented: false
  scope_note: >-
    The token response includes a `scope` field which the client stores, but no scope reference,
    no scope list and no consent screen are published anywhere. Because the scope vocabulary is
    unknown, no scopes/ artifact is written — an empty or invented scope list would be worse than
    the honest absence.
  client_credentials_note: >-
    The authorize call is made as `?client_id=<CLIENT_ID>` with a client_secret held in the SDK.
    This is a confidential-client pattern used from a public (mobile) client.
- id: guest
  type: apiKey
  in: header
  name: Authorization-Guest
  status: observed
  note: >-
    A second, parallel token channel for unauthenticated ticket buyers. The API mints the guest
    token and returns it in the `authorization-guest` RESPONSE header; the client echoes it back
    on subsequent requests. It is the mechanism that lets a fan hold a cart and complete checkout
    without creating an account. Undocumented publicly, and confirmed accepted by the live API —
    `authorization-guest` is listed in Access-Control-Allow-Headers on every /api/ response.
- id: none
  type: none
  status: observed
  note: >-
    A subset of the API is genuinely anonymous and needs no credential at all — confirmed live:
    GET https://www.ticketfairy.com/api/countries/list returns 200 application/json with no
    Authorization header, and GET https://www.theticketfairy.com/api/public/filtered-events
    returns 200 for a brand or venue filter. This public read surface is what the company's own
    WordPress plugin consumes.
media_types:
  request: application/vnd.api+json
  response: application/vnd.api+json
  note: >-
    The client sets JSON:API media types by default and unwraps `data.data.attributes.*` on
    responses, so the authenticated surface is JSON:API-flavored. The anonymous public endpoints
    answer plain application/json with a flat {data, success, error, message, status} envelope —
    the two surfaces do not share an envelope.
accepted_auth_headers_live:
  source: CORS preflight, https://www.ticketfairy.com/api/v1/cart/, 2026-08-13
  headers:
  - authorization
  - authorization-guest
  - x-tf-ecommerce
  - x-tf-context
  - promotion-code
  - promotion-event
  - referrer-id
  - device-info
  - referer-url
  - additional-cookies
  - phpr-remote-event
  - idempotency-key
docs: null
docs_note: >-
  No public authentication page exists. Searched ticketfairy.com and theticketfairy.com for
  /developers, /api, /api-documentation, /docs — all 404.
gaps:
- No published OAuth scope reference, despite the token response carrying a `scope` field.
- No documented token lifetime, refresh flow, or revocation endpoint.
- No /.well-known/oauth-authorization-server or /.well-known/openid-configuration (both 404).
- A client_secret is shipped inside a public npm package and therefore inside every app that
  bundles it.