Skip to main content

Authentication

The service always requires credentials.

What changes by environment is the credential type: one deployment may use API keys, another may use bearer tokens, and another may sit behind gateway or enterprise identity.

What remains stable​

The stable user-facing expectation is:

  • The service is protected.
  • Your client must send whatever credentials your deployment requires.
  • Session access is still subject to authorization even after authentication succeeds.

Common deployment models​

Depending on your environment, authentication may be provided through:

  • API keys.
  • Bearer tokens.
  • Gateway-managed identity.
  • Enterprise identity systems.

The right mechanism depends on how your hosted service is configured.

Integration guidance​

When writing an HTTP client:

  • Use HTTPS.
  • Inject credentials at the HTTP layer, not in request bodies.
  • Keep secrets outside source code.
  • Rotate or scope credentials according to your deployment policy.

Authorization matters separately​

A valid credential does not imply permission to do everything.

Authorization decisions may vary by:

  • Tenant.
  • User.
  • Session ownership.
  • Session source.
  • Workflow stage.
  • Approval state.

Operational advice​

If requests fail unexpectedly:

  1. Confirm you are calling the correct /v1/... route.
  2. Confirm the credential is present in the request.
  3. Confirm the credential is valid for the environment you are targeting.
  4. Confirm the authenticated identity is allowed to access the specific session or source.

What to consult for exact details​

For the exact auth mechanism in your deployment, use the credentials and onboarding material provided with your environment.