Authentication

Authentication establishes the identity of the application or service making an API request.

Authorization determines which resources and operations that identity is permitted to access.

Each Senmo infrastructure product may use its own authentication mechanism. Always consult the relevant product's API reference for the supported credential type and request format.

Authentication methods

Depending on the API, common authentication approaches include:

API keys

An API key identifies an application or integration.

Where supported, API keys must be transmitted using the header or mechanism specified by the API.

Bearer tokens

Some APIs use access tokens supplied through the HTTP Authorization header.

For example:

Authorization: Bearer <access-token>

This is a general bearer-token example and does not imply that all Senmo APIs support this method.

Other authentication mechanisms

Some integrations may require additional credentials, request signing, or provider-specific authorization procedures.

These requirements are documented at the product or endpoint level.

Credential security

Treat API credentials as sensitive secrets.

Follow these practices:

• Store credentials in a secure secret-management system.
• Never expose server-side credentials in browser code.
• Never commit credentials to Git repositories.
• Avoid including credentials in application logs.
• Restrict credential access to authorized applications and personnel.
• Rotate or revoke credentials when required.
• Use separate credentials for separate environments where supported.

Server-side integrations

Sensitive API operations should be performed from a trusted server-side environment.

For example, a Next.js application can communicate with a backend API route that securely manages credentials and calls the external service.

Client Application
        |
        v
Application Backend
        |
        | Authenticated API request
        v
Senmo Platform API

This architecture helps prevent sensitive credentials from being exposed directly to end users.

Authentication failures

Authentication and authorization failures should be handled separately.

A 401 Unauthorized response generally indicates that valid authentication credentials are missing or have not been accepted.

A 403 Forbidden response generally indicates that the request is understood but access is not permitted.

Actual error codes and response bodies depend on the relevant API.

Environment separation

If a platform provides multiple environments, credentials should be associated with their intended environment.

Avoid reusing production credentials in development or testing systems.

Next steps

Review the Environments guide to understand environment separation and configuration practices.

For product-specific authentication details, consult the appropriate InfraRails, Hyperhash, or Foundry API reference.