Skip to main content
Every request to the Murmo API must include an API key sent as a Bearer token in the Authorization header. Create your key in the Murmo app — it will be prefixed with murmo_ and is tied to your user account and wallet. 
Authorization: Bearer murmo_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The key authorizes server-side wallet signing on your behalf, which means it can place trades and move funds into positions without you ever handling a private key. Protect it the same way you would a private key.
Always send the key in the Authorization header only. Never put it in a URL query string — query strings are captured in load-balancer and CDN logs and are visible to infrastructure you don’t control.

​
What a key can and cannot do

Understanding the boundary of a key’s power helps you reason about the blast radius if one is ever exposed.

Allowed

Reads (identity, account, positions, trade history), spot swaps and group trades, prediction market and perp positions, group membership and copy-trade settings, and chat.

Not Allowed

Withdrawing funds to an external address and managing API keys. Both actions require an interactive in-app session and have no REST route. A key cannot drain your wallet.
Funds you deposit can be deployed into trades and positions by the key, but they cannot be withdrawn from your wallet by it. To move money out, log in to the Murmo app directly.
API keys are scoped to the REST API (/api/v1) and the real-time WebSocket gateways. They are not accepted on the GraphQL endpoint (/graphql), which is the interactive app surface and requires a full browser session. Using a key against GraphQL returns 403 Forbidden.

​
Inspect the current credential

Call GET /api/v1/me to confirm the key is valid, see its metadata (never the secret itself), and check your current rate-limit budget.
curl
curl https://api.alpha-labs.trade/api/v1/me \
  -H "Authorization: Bearer $MURMO_API_KEY"
Response
{
  "data": {
    "userId": "d66bafb2-...",
    "authMethod": "apiKey",
    "apiKey": {
      "id": "ak_...",
      "label": "my-bot",
      "prefix": "murmo_froc",
      "lastUsedAt": "2026-06-02T19:00:00.000Z",
      "expiresAt": null,
      "createdAt": "2026-05-20T12:00:00.000Z"
    },
    "rateLimit": { "limit": 1200, "windowSeconds": 60 }
  }
}
The prefix field — for example murmo_froc — is enough to identify which key you’re using in logs without exposing the secret.

​
Rate limits

API-key traffic is limited to 1,200 requests per 60-second rolling window. Exceeding the limit returns 429 Too Many Requests. Back off and retry after the window resets. Your current limit and window size are always visible in the rateLimit object on GET /api/v1/me.
If you’re polling for live prices or chat messages, switch to WebSockets instead. It’s lower latency and doesn’t count against your REST rate budget.

​
WebSocket authentication

The same murmo_ key authenticates the real-time WebSocket gateways. Pass it in the Socket.IO handshake’s auth.token field — or as an Authorization: Bearer header — and never in the query string.
JavaScript
import { io } from "socket.io-client";

const socket = io("wss://api.alpha-labs.trade/perps", {
  transports: ["websocket"],
  auth: { token: process.env.MURMO_API_KEY }, // "murmo_..."
});
See the Real-time overview for available namespaces and events.

​
Error reference

StatusMeaning
401 UnauthorizedThe Authorization header is missing, malformed, or the key is invalid. Check that the key starts with murmo_ and is formatted as Bearer murmo_....
403 ForbiddenThe key is valid but the action is not permitted — for example, you are not a member of the target group, or the action requires an in-app session (such as a withdrawal).
429 Too Many RequestsYou have exceeded 1,200 requests in the current 60-second window. Back off and retry.
See Errors for full response shapes and error codes.

​
Security checklist

Apply these three practices before you ship any bot or agent to production.
1

Store the key in a secret manager

Use an environment variable or a secrets manager (e.g. AWS Secrets Manager, HashiCorp Vault) — never hard-code it in source files or commit it to a repository. If you accidentally expose it in a commit, rotate it immediately.
2

Transmit it only over HTTPS or WSS

Always use TLS. HTTP or WS (plain-text) connections must never carry your key. When logging request metadata, log the prefix field (murmo_froc...) rather than the full key value.
3

Rotate the key if it is ever exposed

Revoke the compromised key in the Murmo app and create a new one. Keys can also be given labels and expiry dates in the app to limit their lifetime by design.