SohoPay operates a dual-layer security model designed for both server-to-server infrastructure and autonomous AI agents:
  1. Server-to-Server API Keys: Used by merchants, fintech platforms, and backend services to manage orders, allowlists, and credit facilities.
  2. Agent & Borrower Identity: Built on OAuth 2.0, non-custodial EIP-712 wallet ownership proofs, and scoped session JWTs for AI agents operating via the Model Context Protocol (MCP).

Authentication models at a glance


API key authentication

Every REST API request must include a secret API key sent as a Bearer token in the Authorization header.

Key formats

API keys are environment-scoped secrets:
Keys only work in their intended environment. Presenting a sk_test_ key to the production gateway or vice versa returns 401 INVALID_API_KEY.

Generating an API key

  1. Sign in to the Merchant Dashboard (or Production Dashboard).
  2. Navigate to Settings → API Keys → Create key.
  3. Provide a descriptive label (e.g. checkout-backend-prod).
  4. Copy the secret key immediately. For security, the full key is displayed only once.

Sending authenticated requests

Include the key in the Authorization header on every call:

Standard error responses

Requests with a missing, malformed, or revoked key return 401 Unauthorized:
Never expose API keys publicly. Do not commit them to version control, embed them in client-side code (frontend JavaScript, mobile apps), or inject them into public AI prompts. All calls must originate from your secure backend.

Agent & borrower authentication (MCP)

When AI agents spend credit or when human operators access the Borrower Portal, authentication relies on cryptographic proofs rather than static API keys:
  1. Social OAuth Linking: The operator links a trusted identity (GitHub, LinkedIn, or X) during the initial CLI pairing (npx @sohopay/mcp-server login).
  2. EIP-712 Wallet Challenge: SohoPay never holds the borrower’s private key. The borrower signs a cryptographic typed data challenge proving ownership of their external Base wallet.
  3. Session Tokens: The gateway issues a scoped, short-lived JWT token used by MCP tools and the portal to execute operations safely.

Webhook signature verification

SohoPay signs every outbound webhook delivery using HMAC-SHA256 to ensure payloads cannot be forged or tampered with in transit. Each webhook request includes two security headers:
  • Sohopay-Signature: The computed HMAC-SHA256 signature.
  • Sohopay-Timestamp: Unix timestamp (in seconds) of when the event was dispatched.

Verifying signatures

Always verify the signature before processing a webhook payload. Compute the HMAC over ${timestamp}.${raw_body} using your webhook signing secret (whsec_...):

Key rotation (zero downtime)

Rotate API keys periodically (e.g. quarterly) or immediately if an exposure is suspected:
1

Create the replacement key

In the dashboard (Settings → API Keys → Create key), generate a new key. The old key remains active simultaneously.
2

Deploy the new key

Update your secrets manager or environment configuration with the new key and deploy your services. Confirm that outbound calls return 200 OK.
3

Revoke the old key

Once all running instances have adopted the new key, revoke the old key in the dashboard. Any remaining requests using the retired key will be rejected with 401 INVALID_API_KEY.
If a key is accidentally committed to a public repository, skip gradual migration: revoke the compromised key immediately, then provision and deploy a fresh key.

Rate limits & request headers

Every API response returns standard rate-limiting metadata: If you hit a rate limit, the API returns 429 RATE_LIMITED. Back off according to the Retry-After header. Per-agent transaction ceilings are enforced independently by the Policy Service.

Next steps

Environment Setup

Review staging vs production endpoints and network configurations.

Webhooks Guide

Register webhook endpoints and handle real-time payment events.

Key Management

Learn how agent MPC signing keys and EIP-712 security work.