Fintary · Authentication Profile

Fintary Authentication

Authentication

Fintary secures its APIs with apiKey and http across 2 declared security schemes, as derived from its OpenAPI definitions.

CompanyFintechInsuranceInsurtechCommissionsRevenue OperationsAnalyticsAgency ManagementPolicy ManagementPayoutsReconciliationOpenAPI
Methods: apiKey, http Schemes: 2 OAuth flows: API key in: header

Security Schemes

BearerAuth http
scheme: bearer
ApiKeyAuth apiKey
· in: header (x-api-key)

Source

Authentication Profile

Raw ↑
generated: '2026-08-14'
method: searched
source: openapi/fintary-ams-api-openapi.yml, openapi/fintary-open-api-openapi.yml
docs: https://api.fintary.com/documentation
summary:
  types:
  - apiKey
  - http
  api_key_in:
  - header
schemes:
- name: BearerAuth
  type: http
  scheme: bearer
  bearerFormat: string
  sources:
  - openapi/fintary-ams-api-openapi.yml
  - openapi/fintary-open-api-openapi.yml
  applies_to: Fintary Open API, Fintary AMS API
- name: ApiKeyAuth
  type: apiKey
  in: header
  parameter: x-api-key
  description: API key for authentication
  sources:
  - openapi/fintary-open-api-openapi.yml
  applies_to: Fintary Open API
application:
  style: global
  note: >-
    Both documents declare a top-level `security` requirement rather than per-operation
    security. The Open API accepts either scheme (`ApiKeyAuth` OR `BearerAuth`); the AMS API
    declares `BearerAuth` only. No operation in either document opts out.
observed:
- url: https://api.fintary.com/openapi/agents
  status: 401
  body: '{"success":false,"data":null,"message":"Missing or invalid API key","statusCode":401}'
  note: Confirms the x-api-key scheme is enforced live.
- url: https://api.fintary.com/api/ams/agents
  status: 401
  body: Not authenticated
  note: Confirms the AMS bearer scheme is enforced live.
key_issuance:
  self_service: false
  note: >-
    Fintary publishes no key-management or token-issuance documentation. There is no
    developer console, no key page, no signup, and no documented token endpoint for the
    APIs themselves. Keys and bearer tokens are obtained through a Fintary representative
    against an existing customer account.
scopes:
  published: false
  note: >-
    Neither document declares an oauth2 securityScheme and no scope or permission reference
    is published, so no scopes/ artifact is emitted. Authorization is expressed instead as
    coarse account roles - `account_admin`, `producer`, `data_specialist` (named in the SSO
    guides) - plus per-operation admin gates in the Open API, where `account_id` and
    `contact_id` overrides are documented as "Fintary Admin only" or "Fintary Admin or
    Account Admin".
sso:
  role: client
  protocol: OAuth 2.0 authorization code
  docs: https://api.fintary.com/documentation
  self_service: false
  note: >-
    Distinct from API authentication. Fintary acts as the OAuth CLIENT against a customer's
    identity provider: the user is redirected to the customer's authorization URL, the IdP
    returns a code to Fintary's redirect URI, Fintary exchanges it at the customer's token
    endpoint using client credentials the customer issues, then decodes the selected JWT and
    reads claims. Fintary publishes no authorization server of its own and issues no
    developer-facing scopes. Setup is performed by Fintary staff from configuration the
    customer supplies.
  variants:
  - id: contact-sync-id-sso
    title: Contact Sync ID SSO
    user_resolution: contact_sync_id
    identity_claim: contact_id
    role_claim: role
    token_source: access_token or id_token
    role_mapping: [account_admin, producer, data_specialist]
    provisioning_flags: [createContactIfMissing, createUserIfMissing]
    fallback: >-
      userResolution.identityFallback = 'email' resolves the user by verified email when the
      identity claim is absent; that path matches existing `users` records only and never
      reads or writes `contacts`.
    forwarded_entry: https://api.fintary.com/oauth/callback?code=<code>&provider=<provider_slug>
  - id: email-sso
    title: Email-based SSO
    user_resolution: email
    identity_claim: email
    token_source: id_token first, falling back to access_token
    provisioning: >-
      Does not create users on the fly - users must be invited into Fintary in advance and
      must be active, or login fails.
  configuration_inputs:
  - provider name/slug
  - Fintary account (customer tenant) to map
  - authorization URL
  - token URL
  - client ID and secret
  - redirect URI(s)
  - scopes and extra authorization parameters
  - token endpoint content type (application/json or application/x-www-form-urlencoded)
transport:
  https_only: true
  hsts: 'max-age=63072000; includeSubDomains'