generated: '2026-08-10' method: probed source: Access-Control-Allow-Headers served by app.centrical.me, docs.centrical.me and powerup.centrical.me published_by_provider: false # READ THIS BEFORE USING THIS FILE. # # Centrical publishes NO authentication documentation. There is no developer portal, no auth page, # no OpenAPI securitySchemes, and no OIDC/OAuth discovery document — /.well-known/openid-configuration # and /.well-known/oauth-authorization-server both 404 on centrical.com and 403 on api.centrical.me. # # Everything below is INFERRED from one thing Centrical's own edge emits anonymously: the # Access-Control-Allow-Headers list its application hosts return on every response. That header # enumerates the request headers the platform is willing to accept, which names the credential # headers by name. That is real, observed, reproducible evidence of the auth surface's SHAPE — it is # not a contract, it does not tell us how to obtain a credential, and it must never be presented as # Centrical-published documentation. # # For this reason NO `type: Authentication` pointer is wired into apis.yml. The # `authentication_documented` check asks whether the PROVIDER documents authentication. Centrical # does not. This file records what we could see, and names the gap. note: >- Inferred auth surface only. Centrical documents authentication to contracted customers inside its Zendesk help center (401 anonymously). No pointer is emitted; this artifact is evidence, not a published contract. summary: types_inferred: [apiKey, http-bearer-jwt, sso-token] api_key_in: [header] oauth2_flows: [] oidc_discovery: false documented: false inferred_schemes: - name: x-api-key type: apiKey in: header parameter_name: x-api-key confidence: high evidence: >- `x-api-key` is listed in Access-Control-Allow-Headers on every Centrical application host. It is also the canonical AWS API Gateway key header, and api.centrical.me is an AWS API Gateway custom domain (x-amzn-errortype: ForbiddenException), which is consistent with key-based edge auth. - name: jwt type: apiKey in: header parameter_name: jwt confidence: medium evidence: >- A bare `jwt` request header is accepted alongside the standard `authorization` header. Which of the two carries the bearer token for the integration API is not determinable anonymously. - name: authorization type: http scheme: bearer confidence: medium evidence: Standard `authorization` header is in the accepted list. - name: ssoToken type: apiKey in: header parameter_name: ssoToken confidence: medium evidence: >- `ssoToken` is accepted, and powerup.centrical.me returns an `ssoredirect` response header — consistent with the enterprise SSO Centrical markets to customers. No SAML/OIDC metadata endpoint is public. - name: Signature type: apiKey in: header parameter_name: Signature confidence: low evidence: >- A `Signature` header is accepted, suggesting request signing on some surface (possibly webhook or inbound callback verification). No algorithm, canonicalization or key distribution is documented. # Non-credential headers the same CORS policy advertises. Captured here rather than in a # conventions/ artifact because Centrical documents none of them — there is no conventions contract # to record, only observed header names. observed_platform_headers: - {header: centri-version, inferred_purpose: API/platform version selection, confidence: medium} - {header: centri-request-id, inferred_purpose: request correlation / tracing id, confidence: medium} - {header: session-id, inferred_purpose: session correlation, confidence: medium} - {header: 'x-cen-1', inferred_purpose: unknown vendor header, confidence: low} - {header: 'g-s-x', inferred_purpose: unknown legacy GamEffective header, confidence: low} - {header: 'g-s-x-t', inferred_purpose: unknown legacy GamEffective header, confidence: low} - {header: 'g-s-i-i', inferred_purpose: unknown legacy GamEffective header, confidence: low} - {header: fromMobile, inferred_purpose: client-surface flag, confidence: low} - {header: fromAdmin, inferred_purpose: client-surface flag, confidence: low} - {header: fromGameapp, inferred_purpose: client-surface flag, confidence: low} - {header: fromGtv, inferred_purpose: client-surface flag, confidence: low} - {header: ManagerOrgUnitId, inferred_purpose: org-unit scoping / impersonation context, confidence: low} - {header: ManagerOrgUnitUserName, inferred_purpose: org-unit scoping / impersonation context, confidence: low} - {header: LoggedBy, inferred_purpose: actor attribution, confidence: low} - {header: 'GE-IGNORE-CACHE', inferred_purpose: cache bypass (GE = GamEffective), confidence: low} - {header: game-id, inferred_purpose: game/program scoping, confidence: low} raw_cors_allow_headers: >- accept, authorization, content-type, Cache-Control, P3P, GE-IGNORE-CACHE, Signature, fromMobile, ssoToken, fromAdmin, fromGameapp, fromGtv, ManagerOrgUnitUserName, ManagerOrgUnitId, g-s-x, g-s-x-t, g-s-i-i, User-Agent, Referer, Origin, Access-Control-Allow-Headers, x-cen-1, jwt, x-api-key, centri-request-id, session-id, centri-version, LoggedBy, test-name, game-id allowed_methods: [GET, POST, PUT, OPTIONS, HEAD] gap_to_close_upstream: >- Centrical could make this an actual artifact by publishing one anonymous page describing how an integrator obtains a credential and which header carries it. Today the only public signal that any of this exists is a CORS preflight allowlist. x-evidence: - {url: 'https://app.centrical.me/', status: 302, checked: '2026-08-10', note: Access-Control-Allow-Headers observed} - {url: 'https://docs.centrical.me/', status: 302, checked: '2026-08-10', note: Access-Control-Allow-Headers observed} - {url: 'https://powerup.centrical.me/', status: 302, checked: '2026-08-10', note: ssoredirect header observed} - {url: 'https://api.centrical.me/.well-known/openid-configuration', status: 403, checked: '2026-08-10'} - {url: 'https://api.centrical.me/.well-known/oauth-authorization-server', status: 403, checked: '2026-08-10'} - {url: 'https://centrical.com/.well-known/openid-configuration', status: 404, checked: '2026-08-09'}