API Authentication

Use the Anthid API reference to explore available endpoints, request parameters, response schemas, and errors.

Authentication

Anthid endpoints use one or more of the following credential types:

Credential	Header	Typical use
Organization API key	`x-api-key: <YOUR_API_KEY>`	Intent submission, ledger queries, controls, connections, instruments, and streaming
User bearer token	`Authorization: Bearer <YOUR_ACCESS_TOKEN>`	User, organization, account, and administrator workflows
Client-credentials bearer token	`Authorization: Bearer <YOUR_SERVICE_TOKEN>`	Service-to-service reads and restricted credential operations

Not every endpoint accepts every credential type. The authentication section on each generated endpoint page is authoritative. Keep credentials private. Do not embed API keys, user tokens, or service tokens in public client-side code.

REST

REST requests use JSON for both request bodies and responses. Include Content-Type: application/json when sending a request body. Organization API key example:

curl https://api.anthid.com/v1/intents \
  -X POST \
  -H "x-api-key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "trading_account_id": "<ACCOUNT_ID>",
    "command": {
      "type": "CREATE",
      "payload": {
        "symbol": "AAPL",
        "order_side": "BUY",
        "order_venue": "SMART",
        "spec": {
          "Market": {
            "quantity": "1"
          }
        }
      }
    }
  }'

User bearer token example:

curl "https://api.anthid.com/v1/accounts?enabled=true" \
  -H "Authorization: Bearer <YOUR_ACCESS_TOKEN>"

Service-account reads that cross organization boundaries may also require:

x-organization-id: <ORGANIZATION_ID>

For service reads that require x-organization-id, a missing or malformed header returns 400. A caller context that requires an organization but has none returns 401; policy denials remain 403. Check the endpoint’s response definitions for its exact access rules.

gRPC

The Streaming API accepts an organization API key or user bearer token in gRPC metadata. This example uses an API key. Clone the public protobuf repository so grpcurl can load the current split service definition.

git clone https://github.com/anthid-labs/proto.git anthid-proto

grpcurl \
  -import-path ./anthid-proto \
  -proto trading/trading_service.proto \
  -H "x-api-key: <YOUR_API_KEY>" \
  -d '{
    "trading_account_id": "YOUR_TRADING_ACCOUNT_ID",
    "environment": "BROKER_ENVIRONMENT_PAPER",
    "subscriptions": ["EVENT_TYPE_BROKER_ORDER"]
  }' \
  stream.anthid.com:443 \
  trading.TradingService/SubscribeEvents

Wire conventions

Use each endpoint’s schema for casing, required fields, and pagination. These conventions differ across APIs:

Value	Wire format
Quantities and prices	Decimal strings, such as `"10"` and `"195.00"`
Page limits, counts, and sequence numbers	JSON integers where the schema declares integers
Ledger environment	`paper` or `live`, required on set queries
Order state / order status	`Open` / `PARTIALLY_FILLED`, with different casing
Catalog asset class / stream instrument class	`EQUITY` / `equity`
Order specification	Single-key object, such as `{"Market":{"quantity":"1"}}`
Catalog instrument	Object tagged by `asset_class`, with class-specific fields

The Instruments API supplies shared reference data. A listed instrument is not a promise of broker trading support. An Idempotency-Key on intent submission makes a retry safe: the same key with the same request is answered with the intent the first one made, and the same key with a different request is refused with 409. See Request correlation and retries before implementing automatic retries.

Support

For questions about authentication, request formats, or API behavior, contact support.

Connections

Organizations

Controls

Accounts

Intents

Ledger

Instruments

Stream

MCP

Billing

API Authentication

Authentication

REST

gRPC

Wire conventions

Support

​Authentication

​REST

​gRPC

​Wire conventions

​Support

Authentication

REST

gRPC

Wire conventions

Support