generated: '2026-07-25' method: searched source: openapi/apollo-insurance-affiliates.yml, openapi/apollo-insurance-covertrack.yml docs: https://docs.apollocover.com/docs/public-affiliate-api/27500feeac1b7-introduction summary: types: - apiKey api_key_in: - header oauth2_flows: [] self_serve: false model: >- A single static API key header, hand-issued by APOLLO to affiliates and property-manager partners, with all authorization carried in path identifiers rather than in the token. No OAuth, no OIDC, no scopes, no token exchange, no rotation endpoint and no /.well-known/ discovery on any host. published_guidance: >- "All endpoints require an `affiliateId` (provided by your APOLLO Contact) and a `insuranceType` in the path. Currently only the `tenant` insurance type is available. All endpoints require a `x-api-key` security token in the header. This token will be provided to you by APOLLO." schemes: - name: apiKeyAuth type: apiKey in: header parameter: x-api-key declared: true applied: 'global security requirement: security: [{apiKeyAuth: []}]' sources: - openapi/apollo-insurance-affiliates.yml - name: x-api-key (undeclared) type: apiKey in: header parameter: x-api-key declared: false applied: >- Present as an explicit header parameter on every path, but with no components.securitySchemes block and no security requirement. On the callback specification it is described as "API Key (recommended)" rather than required. sources: - openapi/apollo-insurance-covertrack.yml - name: none declared type: null declared: false applied: >- The superseded affiliate generation declares an x-api-key header parameter on each operation but no securitySchemes and no security requirement. sources: - openapi/apollo-insurance-affiliates-legacy.yml issuance: self_serve: false provisioning_ui: none process: >- Keys are issued by hand by an APOLLO contact. The documentation is genuinely public — no login wall, no gate, no sign-in prompt — but the integration is partner-scoped. Open docs, closed credentials. request_via: https://apollocover.com/partnerships per_environment: true environments: - {mode: test, host: 'https://o73td82enk.execute-api.ca-central-1.amazonaws.com/1_0_0', api: Affiliates} - {mode: live, host: 'https://fpl95knwc1.execute-api.ca-central-1.amazonaws.com/1_0_0', api: Affiliates} - {mode: test, host: 'https://api.covertrack-dev.ca', api: CoverTrack} - {mode: live, host: 'https://api.covertrack.ca', api: CoverTrack} rotation: not published expiry: not published revocation: not published authorization: model: path-scoped note: >- The token carries no scopes, roles or claims. Every authorization boundary is a path identifier the partner is given — affiliateId on the Affiliates API, and partnerId/propertyId/tenantId on CoverTrack. A key plus a guessed identifier is the only thing between a caller and another partner's data, so identifier entropy is load-bearing. scopes: none detail: conventions/apollo-insurance-conventions.yml failure_modes: '403': Forbidden — invalid token, or a token from the other environment '401': not documented on any operation note: >- APOLLO documents no 401 anywhere. An authentication failure surfaces as 403. end_user_auth: present: false note: >- There is no consumer-facing API and no end-user authorization. Consumers authenticate only on the hosted co-branded launchpad and in the customer portal (https://policy-portal.apollocover.com/), neither of which has a documented API. APOLLO's security page states end users can protect their APOLLO data with two-factor authentication via email — that is a web-app control, not an API one. discovery: well_known: none openid_configuration: 404/403 on every host oauth_authorization_server: 404/403 on every host detail: well-known/apollo-insurance-well-known.yml transport_security: tls_minimum_published: TLS v1.2 (per https://apollocover.com/security) tls_observed: TLSv1.3 on apollocover.com, docs.apollocover.com, api.covertrack.ca and the API Gateway host detail: security/apollo-insurance-domain-security.yml