Bit2Me APIPartner architecture
Parent HMAC, subaccount sessions, and the money path for B2B2C.
Genericize this map for any bank or neobroker. Do not copy a single partner's contract.
Auth layers
| Layer | Mechanism | Used for |
|---|---|---|
| Parent HMAC | x-api-key, api-signature, x-nonce | Create subaccount, server-side treasury |
| Subaccount header | X-SUBACCOUNT-ID: {userId} | User-scoped REST |
| Subaccount session | POST /v1/signin/apikey with userId | Embed widgets, some identity init contracts |
| 2FA | x-totp + x-totp-type: gauth | Withdrawals and other protected ops |
Money path
- Fiat arrives on Bit2Me rails (bank, card, wallet pay).
- Convert on Bit2Me Pro: Wallet → Pro → order → Pro → Wallet (
POST /v1/trading/wallet/depositandPOST /v1/trading/wallet/withdraw). - Deliver either:
- In-network: Social Pay to another Bit2Me user (
email/phone/alias). Local-currency last mile is Argentina only. - On-chain: address-book withdrawal to an external address. Verify the destination the first time. Travel Rule data is on the address-book entry; Travel Rule as a separate call is Wallet legacy only.
- In-network: Social Pay to another Bit2Me user (
Keep your own ledger of fiat allocated per subaccount. A minimum parent fiat balance is required to operate (see Account model). USD is only available on Bit2Me Pro.
Partner trading fees and invoice cadence are contractual. This portal publishes on-chain fees on the withdrawal proforma/draft and Pro min/max on GET /v2/trading/market-config. Do not read a partner bps split from OpenAPI.
This page describes the published API. It is not legal advice. Bit2Me Legal and Compliance must review KYC, KYB, Travel Rule, and 2FA copy before this portal is announced to partners.