Skip to main content

Overview

The Terminal Gateway uses API key-based authentication for both HTTP and WebSocket protocols. Each protocol has a different authentication mechanism:
See a signed request in full, with samples in seven languages, in the List Terminals API Reference.

API Key Provisioning

API keys are provisioned manually by Modulus Labs. To request API credentials:
Terminal Gateway keys do not require a documented prefix. Use the API key exactly as issued rather than changing or inferring its format.
1

Contact support

Email support@moduluslabs.io with your integration details.
2

Provide information

Include your organization name and intended use case (desktop POS, terminal integration, etc.).
3

Receive credentials

You’ll receive an API key and API secret pair. Store these securely.
Never expose your API key or secret in client-side code, version control, or logs. Store them in environment variables or a secure secrets manager.

HTTP API Authentication

HTTP requests require HMAC-SHA256 signature authentication. Each request must include three authentication headers.

Required Headers

String-to-Sign Format

Construct the string to sign using this format:
Where:
  • METHOD - HTTP method in uppercase (GET, POST)
  • PATH - The endpoint path without the /v1/terminal-gateway gateway prefix (e.g., /v1/terminals). See Which path to sign.
  • TIMESTAMP - Value of x-timestamp header
  • SHA256(BODY) - Hex-encoded SHA256 hash of the exact request body you send (empty string hash for GET requests)

Which path to sign

Requests reach the Terminal Gateway through the API gateway, which serves it under the /v1/terminal-gateway prefix. That prefix is part of the URL you call, but it is not part of the path you sign. The signature is verified against the endpoint path alone. The same rule applies to every endpoint:
Signing the full URL path (for example /v1/terminal-gateway/v1/terminals) is the most common cause of Invalid HMAC signature errors. Sign only the endpoint path, starting at /v1/terminals or /v1/transactions. Don’t include the host, the /v1/terminal-gateway prefix, or a query string.

Sign the exact body you send

The gateway hashes the raw request body as it receives it. Serialize your JSON once, hash that string, and send that same string. If your HTTP client re-serializes the body (different key order, spacing, or escaping), the hash no longer matches and the signature is rejected.

Signature Computation

Example

For a GET request to /v1/terminals at 2024-01-15T10:30:00.000Z:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is the SHA256 hash of an empty string.

Code Examples

Authentication Errors

A failed authentication returns 401 Unauthorized. The body has no code field; identify the cause from message:
The gateway does not say why a signature failed. A wrong secret, a wrong path, and a mismatched body all return the same Unauthorized: Invalid HMAC signature message. Quote the requestId when you contact support.

Troubleshooting Invalid HMAC signature

Work through these in order. The first two cover most failures.
1

Check the signed path

Sign /v1/terminals, not /v1/terminal-gateway/v1/terminals. Drop the host, the gateway prefix, and any query string. See Which path to sign.
2

Check the body

Hash the exact string you send. For GET requests, hash the empty string (e3b0c442...b855).
3

Check the timestamp

Use the same value in x-timestamp and in the string to sign.
4

Check the method and separators

The method must be uppercase. Join the four parts with a single \n (no trailing newline, no \r\n).
5

Check the secret and encoding

Use the API secret paired with your API key. Output the signature as Base64 (not hex) and the body hash as hex (not Base64).

WebSocket API Authentication

WebSocket connections authenticate during the connection handshake. Provide your API key via headers or query parameters.

Authentication via Headers

Include the x-api-key header in your WebSocket connection request:

Authentication via Query Parameter

Alternatively, pass your API key as a query parameter:
When using query parameters, your API key may appear in server logs. Use header-based authentication in production when possible.

Code Examples


Security Best Practices

Protect Credentials

Store API keys and secrets in environment variables or a secure secrets manager. Never hardcode them in source code.

Use Headers for WebSocket

Prefer header-based authentication over query parameters to avoid keys appearing in logs and browser history.

Synchronize Time

For HTTP API, ensure your system clock is synchronized with NTP. Timestamps must be within 5 minutes of server time.

Rotate Keys

Rotate API keys periodically and immediately if you suspect compromise. Contact support for key rotation.

Next Steps

HTTP Quickstart

Start integrating with the HTTP API

WebSocket Quickstart

Start integrating with the WebSocket API

Core Concepts

Learn about device enforcement and reconnection resilience

API Reference

Request and response fields for every endpoint