Niural · Authentication Profile

Niural Authentication

Authentication

Niural uses a bespoke two-step credential exchange. Client credentials created in the dashboard are POSTed to /authenticate, which returns a JWT access token (3600s), a refresh token, and expires_in. That token is presented as an HTTP bearer credential on every other operation. It is client-credentials shaped but is NOT OAuth 2.0 — there is no grant_type, no token_type, no scope, no /.well-known/oauth-authorization-server, and therefore no scope surface.

Niural secures its APIs with http across 1 declared security scheme, as derived from its OpenAPI definitions.

CompanyPayrollHuman ResourcesEmployer of RecordContractor ManagementGlobal PaymentsInvoicingComplianceFintech
Methods: http Schemes: 1 OAuth flows: API key in:

Security Schemes

BearerAuth http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-08-04'
method: searched
source: openapi/niural-public-api-openapi.yml
docs: https://docs.niural.com/docs/authentications
description: >-
  Niural uses a bespoke two-step credential exchange. Client credentials created
  in the dashboard are POSTed to /authenticate, which returns a JWT access token
  (3600s), a refresh token, and expires_in. That token is presented as an HTTP
  bearer credential on every other operation. It is client-credentials shaped but
  is NOT OAuth 2.0 — there is no grant_type, no token_type, no scope, no
  /.well-known/oauth-authorization-server, and therefore no scope surface.
summary:
  types:
  - http
  api_key_in: []
  oauth2_flows: []
schemes:
- name: BearerAuth
  type: http
  scheme: bearer
  bearerFormat: JWT
  sources:
  - openapi/niural-public-api-openapi.yml
  applied: global (root-level security), exempted only on POST /authenticate
credential_exchange:
  endpoint: POST /authenticate
  hosts:
  - https://api-sandbox.niural.com
  - https://api-live.niural.com
  request: {client_id: uuid, client_secret: string}
  response: {access_token: JWT, refresh_token: string, expires_in: 3600}
  errors: [400 Invalid Request, 422 Validation error, 500 Server Error]
  docs: https://docs.niural.com/docs/authentications
credential_management:
  created_in: Niural dashboard — Organization > Developer > API Keys
  naming: Keys are named by the operator (e.g. "staging", "production").
  secret_visibility: Shown once at creation; recoverable only by rotating the key.
  rotation: Rotating invalidates the previous client secret immediately.
  docs: https://docs.niural.com/docs/auth-keys
required_headers:
- {name: Authorization, value: 'Bearer <access_token>'}
- {name: Accept, value: application/json}
- {name: Content-Type, value: application/json}
scopes:
  supported: false
  note: >-
    No scope, permission or role model is published. A Niural API key is
    all-or-nothing across contracts, invoices and money movement — there is no way
    to issue a read-only credential to an agent or a third party.
gaps:
- No OAuth 2.0 / OIDC discovery document on any host.
- No scoped or restricted keys, so least-privilege delegation is impossible.
- Token lifetime is fixed at 3600s with no documented refresh-token lifetime or
  revocation endpoint.