Environments at a glance
SohoPay runs two isolated environments. Keys, agents, orders, and webhooks never cross between them.SohoPay is pre-mainnet. The mainnet environment is documented here so you can prepare your configuration, but production access is rolling out to beta integrators first. Ask in the beta Slack (see Support) for your onboarding slot.
- Sandbox
- Mainnet
Point your client at the sandbox base URL with a Sandbox agents come with test credit lines and auto-signing (
sk_test_ key:"signature": "sandbox_auto"), so you can settle payments without touching a wallet. Settlement lands on Base Sepolia in about a second, and you can verify transactions on Sepolia Basescan.Base RPC configuration
You only need direct RPC access if you verify settlements on-chain yourself or run your own signing infrastructure. The SohoPay API handles all chain interaction otherwise.
Example viem client for Base Sepolia:
Test USDC faucet
Sandbox agents do not need test USDC — their credit lines are pre-funded, and settlement runs against SohoPay’s sandbox liquidity. You only need faucet USDC for one scenario: testing vault funding with deposits from a wallet you control. For that case, use Circle’s official faucet:- Go to faucet.circle.com.
- Select Base Sepolia as the network.
- Paste your wallet address and request USDC.
POST /vault/deposit.
API key storage
Treat API keys like passwords. The two prefixes make leaks easy to spot in logs — but the goal is never having them in logs at all.- Environment variables — the minimum bar. Load from
.envlocally and keep.envin.gitignore. Never hardcode a key in source. - Secrets managers — for anything deployed: AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or 1Password for teams. Inject at runtime; don’t bake keys into container images.
- One key per service — give each deployed service its own key so you can rotate or revoke one without touching the others.
- Separate sandbox and mainnet configs — keep them in different secret scopes so a staging deploy can never pick up a
sk_live_key.
Network troubleshooting
Common connectivity issues, roughly in the order they occur:401 INVALID_API_KEYon a key that works elsewhere — you’re crossing environments: ask_test_key againstapi.sohopay.xyz(or vice versa). Check the base URL first.- DNS or TLS failures — corporate proxies sometimes block
.xyzdomains. Confirm withcurl -v https://api-sandbox.sohopay.xyz/v1/healthand allowlist both API hosts in your egress rules. 429 RATE_LIMITED— back off for the number of seconds in theRetry-Afterheader. Per-agent limits are enforced by the Policy Service; see Rate Limits.- Timeouts on public RPC —
sepolia.base.orgthrottles aggressively. Retry with backoff or switch to a dedicated provider. - Payments stuck in
pending— the MPC design is fail-closed: if the Policy Service is unavailable, no settlements occur. Check API health and the maintenance window (Sun 02:00–02:30 UTC) before debugging your own code. See SLA.
request_id from the error envelope and follow Troubleshooting.
Next steps
Authentication & Security
Key formats, Bearer auth, rotation, and webhook signing.
Integration Paths
Pick the merchant, agent, or end-to-end track.
Testing Guide
Simulate failures and edge cases in the sandbox.

