generated: '2026-09-06' method: searched source: https://partner.discoverglobalnetwork.com/going-live-with-discover?tab=developer-guide docs: - https://partner.discoverglobalnetwork.com/going-live-with-discover?tab=developer-guide - https://partner.discoverglobalnetwork.com/products/discover-stored-token-services?tab=api-specs - https://partner.discoverglobalnetwork.com/products/iin-data-lookup?tab=api-specs note: >- Cross-cutting semantics read from Discover's public developer guide and product API Specs tabs. Discover publishes no OpenAPI, so nothing below is derived from a spec; every claim traces to a documented statement or a live probe recorded in this repo. authentication: style: OAuth 2.0 client credentials bearer token, plus a per-API second factor (signed JWT in X-DFS-C-APP-JWT, or a consumer application certificate in X-DFS-C-APP-CERT), plus mTLS where the API requires it. detail: authentication/discover-authentication.yml transport: tls: TLS 1.2 or TLS 1.3 required media_type: application/json cache_control: 'no-store (documented as a mandatory request header)' required_headers: - name: Authorization value: Bearer presence: mandatory - name: X-DFS-API-PLAN presence: mandatory description: The API plan issued at onboarding. Routes the call to Sandbox, Certification or Production and carries the rate-limit / quota terms of the partner's service agreement. Required on API calls AND on the OAuth token request. - name: X-DFS-C-APP-JWT presence: conditional description: Second-factor JWS token, on APIs that require it. - name: X-DFS-C-APP-CERT presence: conditional description: Consumer application certificate, on APIs that require it. - name: X-Request-ID presence: mandatory description: A unique reference for the request, freshly generated by the client for every API call. - name: Accept presence: mandatory - name: Content-Type presence: mandatory request_tracing: header: X-Request-ID body_fields: [requestId, taskId, recordLevelId, responseId] shape: UUID description: >- Correlation is doubled up - an X-Request-ID header on every call and a client-generated requestId UUID inside most payloads, echoed on the response. Long-running bulk work is tracked by taskId, and per-record work by recordLevelId. idempotency: supported: false coverage: none mechanism: null detail: >- Discover documents no idempotency key. X-Request-ID is explicitly specified as "freshly generated by the Client for every API Call", which is the opposite of a replay key. The API does detect some duplicates server-side and rejects them - error 10023 "Duplicate request. The request was identified as duplicate for the given transaction" and 10123 "Duplicate recordLevelId in the request" - but that is a rejection, not a documented safe-retry contract: nothing states that replaying a call returns the original result rather than an error, and no retention window is published. An agent cannot safely retry a write against this API today. evidence: - https://partner.discoverglobalnetwork.com/going-live-with-discover?tab=developer-guide - errors/discover-error-codes.yml reversibility: status: documented grade: documented detail: >- A reversal path exists and is named, but no window is published, so this grades `documented` and not `verified`. write_surfaces: - operation: Token lifecycle state change endpoint: POST /globalpymt/ddx/stored-payment-token/aggregator/v1/tokens/state reversal: Yes - the same endpoint takes an operationType; the published example uses "Unlink" and the product docs state "suspension and resumption are also possible". window: not stated docs: https://partner.discoverglobalnetwork.com/products/discover-stored-token-services?tab=api-specs - operation: Token operations state change endpoint: POST /globalpymt/ddx/stored-payment-token/operations/v1/token/state reversal: Yes - same suspend / resume / unlink lifecycle surface at the operations tier. window: not stated docs: https://partner.discoverglobalnetwork.com/products/discover-stored-token-services?tab=api-specs - operation: Bulk card account enrollment endpoint: POST /globalpymt/cardmgmt/account-card/v1/bulkEnrollAccountCard reversal: not documented window: not stated gaps: - No reversal window is stated anywhere in the public documentation for any write surface. - Device de-registration and account closure appear only as error states (10041, 10045, 10047), never as a documented undo operation. dry_run_mode: supported: false detail: >- No dry-run / validate-only mode is documented. The nearest published affordance is a separate Sandbox and Certification environment, selected by the X-DFS-API-PLAN header - a whole environment, not a per-call rehearsal. sandbox: sandbox/discover-sandbox.yml pagination: style: query-parameter page size, observed not documented evidence: >- The Country Acceptance v2 API that travel.discoverglobalnetwork.com calls accepts ?pagesize= (observed live 2026-09-06). No pagination contract - cursor, next link, total count - is published for any product. documented: false versioning: scheme: uri-path detail: The major version is a path segment - .../account-card/v1/..., .../boarding/v2/..., .../cryptogram/v2/..., /v1/iins. Versions coexist per service; there is no version header and no date-pinned version. current: mixed - v1 and v2 by service policy_published: false error_envelope: shape: '{ "code": "", "message": "" }' multiple_messages: true rfc9457: false catalog: errors/discover-problem-types.yml registry: errors/discover-error-codes.yml rate_limit_signaling: headers_published: false detail: >- Rate limits and quotas exist and are bound to the API Plan ("Your API plan controls routing to the endpoints to manage rate limits and quotas based on your organization's service agreement"), but no numeric limit, no window, no RateLimit-* / X-RateLimit-* response header and no 429 semantics are published. Error 10111 ("The one-time password request limit was reached. Often a rate limit issue.") is the only rate-limit-shaped code in the registry and it is scoped to OTP. detail_artifact: rate-limits/discover-rate-limits.yml payload_security: jwe: request and response payload or field-level encryption jws: payload signature and non-repudiation; Discover signs its responses nested_jwt: JWS-in-JWE hashing: SHA-256 content_hash claim detail: authentication/discover-authentication.yml health_checks: convention: every DDX service publishes a POST v1/healthcheck (or v2) sibling returning {healthy, message, version, platform, timestamp} examples: - /globalpymt/cardmgmt/account-card/v1/healthcheck - /globalpymt/ddx/stored-payment-token/boarding/v2/healthcheck - /globalpymt/ddx/stored-payment-token/cryptogram/v2/healthcheck - /globalpymt/ddx/stored-payment-token/operations/v1/healthcheck - /globalpymt/ddx/stored-payment-token/assets/v1/healthcheck method_convention: detail: >- Discover's documented surface is POST-dominant - even reads such as the token account details query are POST (.../operations/v1/token-account-details/actions/query) and the health checks are POST. The IIN Data Lookup Service is the exception, with real GET reads (/v1/iins, /v1/iins/summary, /iins/{network}/summary) alongside a POST single-IIN lookup. cross_links: authentication: authentication/discover-authentication.yml scopes: scopes/discover-scopes.yml errors: errors/discover-problem-types.yml lifecycle: lifecycle/discover-lifecycle.yml rate_limits: rate-limits/discover-rate-limits.yml sandbox: sandbox/discover-sandbox.yml