Skip to main content
Base URLs:
  • Production: https://api.machines.cash/partner/v1
  • Sandbox: https://dev-api.machines.cash/partner/v1
Get API access: email help@machines.cash or DM @erturkarda on Telegram. All requests are JSON. Use X-Partner-Key for steps 1-2. Use Authorization: Bearer <SESSION_TOKEN> for the rest.

1. Create a session token

Call POST /sessions.
Use this session token for steps 3-9. Call POST /users/resolve.

3. Get KYC field requirements and values

Call GET /kyc/values to build your KYC form. The full occupation list is also available at /kyc-values.

4. Submit KYC

Call POST /kyc/applications.

5. Complete verification

Open the completionLink (or externalVerificationLink) in a new window so the user can finish verification.

6. Poll KYC status

Call GET /kyc/status until the status is approved. Status meanings are listed in KYC status reference.
Call GET /agreements to fetch agreement text, then POST /agreements to accept.

8. Discover and create a deposit

Use the deposit flow in this order:
  1. GET /deposits/assets
  2. POST /deposits/range
  3. POST /deposits/estimate
  4. POST /deposits
List assets:
Get range:
Get estimate:
Create deposit:
Example create response fields:
  • deposit.depositAddress: send funds here.
  • deposit.payinExtraId: memo/tag to include when required by source network.

9. Check deposit status and balances

Use GET /deposits/ to check status. Balances typically refresh within a few minutes after completion.
Fetch balances with GET /balances:

Optional: Quote a withdrawal route

Withdrawal flow uses:
  1. GET /withdrawals/assets
  2. POST /withdrawals/range
  3. POST /withdrawals/estimate
  4. POST /withdrawals
Withdrawal routes are dynamic (BTC/SOL/EVM and others). Always query assets, range, and estimate before creating a withdrawal. For create requests, source.contractId is optional. Example estimate request:
Create responses include relay metadata (payinAddress, payinExtraId, payoutAddress, payoutExtraId) and execution fields used for onchain signing/broadcast. Execute from the same adminAddress you used in create, and send the tx to execution.callTarget (not the collateral proxy). For coordinator_v2, include the additional admin typed-data signature inputs.

10. Create a card session token

For card creation, labels, and card secrets, mint a new session token with POST /sessions. Use this token for steps 11-14.

11. Encrypt a card label (optional)

If you want to display a card label to your users, encrypt it with POST /encryption/encrypt and pass it as encryptedName when creating the card.

12. Create a card

Call POST /cards with an optional card label and limit.

13. Create a card secrets session

Call POST /cards/secrets/session.

14. Fetch card secrets

Call POST /cards//secrets with the session id from the previous step. This returns encrypted PAN and CVC only (not the card label).

15. Decrypt PAN and CVC (server-side)

Use the secretKey from Step 13 to decrypt the card number and CVC. This step is typically handled server-side (or by an agent) and never exposed to the browser.