Unknown block type: SchoolHeader
Unknown block type: SchoolNav

For your developers

APIs & Integrations

Everything the portal does, the API does. Clients, accounts, payments and partners are all reachable over REST, and anything that happens comes back to you as a signed webhook.

  • REST
  • JSON
  • OAuth 2.0
  • Webhooks
  • Sandbox
See the endpoints Talk to us
Create a client 
POST https://api.yourdesk.com/v1/clients
Authorization: Bearer sk_live_9f2c…
Content-Type: application/json

{
  "email": "[email protected]",
  "first_name": "Ana",
  "country": "AE",
  "partner_id": "ib_4417",
  "start_kyc": true
}

201 Created
{
  "id": "cl_5512",
  "status": "pending_verification",
  "portal_url": "https://portal.yourdesk.com/…"
}

What you can reach

Four groups, one key

The same objects your desk works with in the console, addressable the way a developer expects to address them. Paged, filterable, and versioned so an upgrade never breaks a script you wrote last year.

  • Clients

    Records, documents and verification status.

    • GET
      /v1/clientsList and filter every client record
    • POST
      /v1/clientsCreate a client and start verification
    • GET
      /v1/clients/{id}/documentsKYC files and the result of each check
    • PATCH
      /v1/clients/{id}Update details, tags or the assigned desk

  • Accounts

    Trading accounts on every platform you run.

    • POST
      /v1/accountsOpen an account on MT5, cTrader or any other
    • GET
      /v1/accounts/{id}Balance, equity, leverage and group
    • POST
      /v1/accounts/{id}/transfersMove funds between a wallet and an account
    • GET
      /v1/accounts/{id}/tradesClosed positions with volume and result

  • Payments

    Everything that touches the ledger.

    • POST
      /v1/depositsPost a deposit against a client wallet
    • POST
      /v1/withdrawalsRaise a request into the approval queue
    • GET
      /v1/transactionsEvery movement with its provider reference
    • DELETE
      /v1/withdrawals/{id}Cancel a request that has not been released

  • Partners

    The IB tree, its rules and what it is owed.

    • GET
      /v1/partnersThe whole tree with tiers and rates
    • GET
      /v1/partners/{id}/commissionsAccrued and paid rebates by period
    • POST
      /v1/partners/{id}/payoutsRelease a payout to the partner wallet
    • PATCH
      /v1/partners/{id}Change tier, rate or parent in the tree

Webhooks

Told, not polled

Anything worth reacting to arrives at your endpoint as it happens, signed, retried on failure and replayable from the console for the day one of your servers was down.

  • client.verifiedKYC came back clean and the account can be funded
  • deposit.confirmedA payment cleared and the wallet has been credited
  • withdrawal.approvedA request passed its approval rule and was released
  • account.openedA trading account was created on one of your platforms
  • partner.commission.accruedA trade earned a rebate somewhere in the tree
  • kyc.expiredA document passed its expiry and the client needs re-checking
deposit.confirmed 
POST https://yourdesk.com/hooks/vast
X-Vast-Signature: t=1757410233,v1=9f2c…

{
  "event": "deposit.confirmed",
  "id": "evt_8Kd21",
  "created": 1757410233,
  "data": {
    "client_id": "cl_5512",
    "account_id": "ac_77310",
    "amount": 2500.00,
    "currency": "USD",
    "method": "upi",
    "provider_ref": "psp_9931x"
  }
}

Questions about the API

Before you write against it

What a technical team asks before it builds anything on top of somebody else’s platform.

  • It comes with it. Every plan has the API, the webhooks and a sandbox, because a CRM your own systems cannot talk to is a CRM you will end up exporting out of by hand. There is no separate developer tier and no per-call charge for ordinary use — rate limits exist to keep one script from affecting everyone else, and they are set high enough that normal integration work never meets them.

  • Server-to-server calls use API keys over TLS; anything acting for a signed-in user goes through OAuth 2.0. Keys are scoped the same way an operator role is, so a key written for a reporting job can read and nothing more, and each one can be limited to a list of addresses. Keys are rotated without downtime by keeping the old one alive while the new one is deployed, and every call is written to the same audit trail as an action taken in the console.

  • They are retried on a backoff for as long as it takes, and anything still undelivered is held so you can replay it from the console once you are back. Every delivery carries a signature and an event id, so you can verify it came from us and drop the duplicate if a retry arrives after the first one finally landed. Build the handler to be idempotent on that id and an outage becomes a delay rather than a hole in your data.

  • Not without warning and not without a version change. The path carries the major version, new fields are added rather than existing ones being repurposed, and anything genuinely breaking goes into the next version with the old one kept alive while you move. You get a sandbox that runs the new version first, so the migration is something your team schedules rather than something that arrives on a Monday morning.

  • Usually, and it is worth asking. The common ones — email and SMS providers, live chat, analytics, ticketing, accounting and the trading platforms themselves — are already wired in. For the rest we build against whatever the tool does offer, which is sometimes a proper API and sometimes a scheduled file drop. Tell us what your desk runs and we will tell you which of the two it is before you commit to anything.