Sofi Technologies Authentication

specification: API Commons Authentication
specificationVersion: '0.1'
provider: SoFi Technologies
providerId: sofi-technologies
generated: '2026-09-06'
method: searched
source: https://docs.tech.sofi.com/pro/reference/api-reference-authentication
docs:
  - https://docs.tech.sofi.com/pro/reference/api-reference-authentication
  - https://docs.tech.sofi.com/pro/docs/quickstart
  - https://docs.tech.sofi.com/pro/docs/environments
  - https://docs.tech.sofi.com/pro/docs/sofi-tech-solutions-tools
description: >-
  Authentication on the SoFi Tech Solutions platform is split three ways, and the largest surface
  is the one the specifications do not describe. A mechanical derivation from openapi/ finds only
  two bearer-style schemes, on the Loan and Risk APIs; it finds nothing at all on the 167-operation
  Program API, because that API authenticates with credentials carried as ordinary form parameters
  in the request body and declares no securityScheme. This artifact was upgraded from that thin
  derivation by reading the provider's Authentication reference page.
summary:
  types: [body-parameter, http-bearer, apiKey]
  api_key_in: [body, header]
  oauth2: false
  openid_connect_for_api: false
  mtls: false
  spec_declares_program_api_auth: false
schemes:
  - name: program-api-credentials
    type: body-parameter
    surface: Program API 4.0 (167 operations) - and the platform's default
    declared_in_spec: false
    parameters:
      - { name: apiLogin, required: true, type: string, max_length: 50, description: 'Username for the requesting IP address, provided by SoFi Tech Solutions' }
      - { name: apiTransKey, required: true, type: string, max_length: 15, description: 'Password for the requesting IP address, provided by SoFi Tech Solutions' }
      - { name: providerId, required: true, type: integer, max_digits: 10, description: 'Provider identifier from SoFi Tech Solutions' }
      - { name: transactionId, required: true, type: string, max_length: 60, description: 'Caller-generated per-request id, UUID preferred; also the idempotency key on 35 endpoints' }
      - { name: providerTransactionId, required: false, type: string, max_length: 60, description: 'Optional caller id for internal reporting; echoed back' }
      - { name: providerTimestamp, required: false, type: date-time, format: 'YYYY-MM-DD hh:mm:ss', description: 'Optional caller timestamp; echoed back' }
    content_type: application/x-www-form-urlencoded
    transport: HTTPS; TLS 1.2 minimum, TLS 1.3 strongly recommended
    ip_binding: true
    ip_binding_note: >-
      Credentials are issued for a specific requesting IP address. A call from an unregistered IP
      returns status_code 21. This is a meaningful second factor - a leaked apiLogin/apiTransKey
      is not usable from an arbitrary host - and it is also why these APIs cannot be called from
      ephemeral or serverless egress without coordination.
    rotation: >-
      Sandbox credentials must be regenerated every 30 days by the company's Sandbox team admin;
      stale details fail the request and can lock the company account. No rotation policy is
      published for Client Validation or Production.
    failure_codes:
      - { code: 4, meaning: Failed API login }
      - { code: 18, meaning: Unauthorized access to this version of the API }
      - { code: 21, meaning: Unregistered IP address }
      - { code: 29, meaning: Incorrect provider ID }
      - { code: 50, meaning: Invalid JWT }
  - name: bearerAuth
    type: http
    scheme: bearer
    bearerFormat: JWT
    declared_in_spec: true
    sources:
      - openapi/sofi-technologies-auth-api-openapi.json
      - openapi/sofi-technologies-risk-api-1-0-openapi.json
      - openapi/sofi-technologies-risk-api-2-0-openapi.json
    note: >-
      On the Auth API this secures the CLIENT's webhook endpoint - SoFi Tech Solutions is the
      caller presenting the token, not the other way round. On the Risk APIs the scheme name in
      the contract is gft-internal-service-auth.
  - name: BearerAuth
    type: apiKey
    in: header
    parameter: Authorization
    declared_in_spec: true
    sources: [openapi/sofi-technologies-loan-api-openapi.json]
    spec_description: |-
      Authorization header is required for requests

      For more information click [here](link)
    note: >-
      Modelled as an apiKey in the Authorization header rather than as http/bearer, and its
      description carries an unresolved "[here](link)" placeholder - the contract points at
      documentation that was never linked.
console_sso:
  applies_to: the SoFi Tech Solutions web tools (Console, Config, CST, gAnalytics, Client Portal)
  applies_to_api: false
  mechanism: SSO from the client's own enterprise identity provider
  supported_idps: [Okta, Microsoft Entra ID, Google, 'any OpenID Connect provider']
  note: >-
    OIDC is used to sign humans into the consoles. It is NOT an API authorization mechanism and no
    /.well-known/openid-configuration is served on any SoFi host - see
    well-known/sofi-technologies-well-known.yml.
  docs: https://docs.tech.sofi.com/pro/docs/sofi-tech-solutions-tools
oauth_scopes:
  published: false
  note: >-
    No OAuth 2.0 anywhere on the API surface, therefore no scopes. derive-oauth-scopes.py found
    zero oauth2 securitySchemes across the 11 definitions and no scopes artifact was written.
gaps:
  - >-
    The platform's primary authentication mechanism is invisible to any tool that reads the
    OpenAPI. A client generated from openapi/sofi-technologies-program-api-openapi.json will not
    send credentials at all.
  - >-
    Credentials travel in the request body rather than in a header, so they land in any
    intermediary that logs request bodies, and they cannot be scoped, expired or revoked
    independently of the account.
  - No published rotation policy for production credentials.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com