generated: '2026-08-23'
method: searched
source: https://docs.jodo.in/getting-started/authentication/
docs: https://docs.jodo.in/getting-started/authentication/
summary:
  types:
  - http
  model: >-
    Single-scheme HTTP Basic Auth over TLS. Jodo issues an API key and secret per institute per
    environment and shares them out-of-band; there is no self-service key provisioning, no OAuth,
    no OpenID Connect and no scope model. Credentials are institute-wide and environment-scoped —
    the same pair authorises every documented operation, so there is no least-privilege boundary
    an integrator can apply within an environment.
  credential_delivery: out-of-band (shared by Jodo per institute and environment)
  self_service: false
  scopes: none
  token_lifetime: n/a (static credential)
schemes:
- name: basicAuth
  type: http
  scheme: basic
  in: header
  header: Authorization
  format: 'Basic <base64(api_key:api_secret)>'
  description: >-
    All Jodo APIs are authenticated using HTTP Basic Auth. Jodo shares separate API keys and secrets
    for the UAT/sandbox and production environments. Applied globally in the spec — every documented
    operation requires it.
  docs: https://docs.jodo.in/getting-started/authentication/
  applies_to: all operations
  sources:
  - openapi/jodo-integrations-openapi.yml
  - https://docs.jodo.in/getting-started/api-structure/
  provider_guidance:
  - 'Docs caution: "Do not expose API keys or secrets in browsers, mobile apps, or client-side code."'
  - >-
    The Android, React Native and Web platform guides all instruct the integrator to mint the
    hosted-flow redirect_url from their own backend rather than calling Jodo from client code.
  code_snippet_note: >-
    Several reference pages show credentials embedded in the URL userinfo
    (https://JODO_API_KEY:JODO_API_SECRET@JODO_API_HOST/...). This works but leaks credentials into
    logs, shell history and proxy traces; the Authorization header form shown elsewhere in the same
    docs is the safer pattern.
end_user_delegation:
  mechanism: short-lived access token for Jodo-hosted flows
  description: >-
    Separate from API authentication. GET /api/v1/integrations/erp/users/{registration_id}/access_token
    returns an access_token plus expires_at, used to redirect a parent or student into a Jodo-hosted
    experience at https://[base_url]/consumer/login-redirect?access_token=<token>. This token
    authenticates the END USER into Jodo's hosted UI; it is not an API credential and cannot be used
    against the ERP integration endpoints.
  docs: https://docs.jodo.in/user/api/get-access-token/
webhook_authentication:
  direction: inbound to the integrator
  mechanisms:
  - name: HMAC signature
    header: X-Jodo-Signature
    algorithm: HMAC SHA-256 hex digest over the raw request body
    secret: shared secret_key configured per subscription on POST /api/v1/integrations/erp/webhooks
  - name: custom header
    description: An agreed header_key/header_value pair Jodo sends with webhook requests.
  - name: source IP allowlist
    production: [3.6.234.242, 3.111.80.40, 13.232.24.175, 43.204.202.190]
    uat: [3.108.86.33, 13.127.40.177, 65.0.77.215]
  docs: https://docs.jodo.in/webhooks/security/
gaps:
- No OAuth 2.0 or OpenID Connect surface, therefore no scopes and no delegated third-party access.
- No documented key rotation procedure, key expiry, or credential lifecycle.
- No documented mTLS option despite the API carrying payment and lending instructions.
- >-
  Basic Auth credentials are institute-wide: an ERP integration that only needs to read configuration
  holds the same credential that can create payment links and cancel payments.