Integration, honestly explained.

01Overview

SQARME CMD is a managed SaaS that runs a private, isolated Binance P2P (INR/USDT) trading engine for each merchant. You use it through a session-cookie web dashboard — the live command deck — not by calling an API. Today there is no public developer REST API for building third-party integrations on top of SQARME.

The integration that exists is deliberately narrow and purpose-built:

• Your Binance account. Your engine automates your own Binance account using your own Binance API key. SQARME is software only — it is non-custodial and never holds, controls or transmits your crypto or fiat. All trades execute on your Binance account.
• The web dashboard. You manage live orders, balances, P&L and settings from the browser. Authentication is a server-side session — see Cookie Policy.
• One-Tap Pay links. The one externally reachable surface: a sharable, token-signed UPI payment link you generate for a counterparty. Described in section 03 (Pro plan and above).

If you are evaluating whether SQARME fits a programmatic workflow, read the security model below, then write to care@sqarme.com with your use-case.

02Security & architecture model

SQARME runs one operating-system process per merchant, each with its own data directory and its own encryption keys. There are no shared encryption keys across merchants. The integration surface is intentionally small, which keeps the security model simple to reason about.

Your Binance credentials

During signup, your API key and secret are validated live against Binance. The control plane uses the secret in memory only to validate, then discards it — the secret is never stored by the control plane. On your own engine, your API key and secret are encrypted at rest (Fernet) into a file using a key derived from your master password (PBKDF2-HMAC-SHA256, 600,000 iterations). They are decrypted only into memory at login and are never written to the OS environment.

Login & access

After onboarding you log in with your email and master password plus a TOTP two-factor code; an optional fund password can gate sensitive actions. Approvals and alerts are linked to your account over Telegram with a one-time 6-digit code.

Internal service communication

Internal messages between your engine, the control plane and the master service are signed with HMAC-SHA256 over per-tenant secrets on a private loopback channel. This is an internal trust mechanism, not a public API — these signed messages are not reachable or callable by third parties, and the signing secrets are not issued to merchants.

03One-Tap Pay links

One-Tap Pay is the only externally reachable, token-gated surface in the product, and it is a sharable link, not a programmatic API. It is available on the Pro plan and above — see Plans.

Conceptually, the flow works like this:

1. From your dashboard, you generate a One-Tap Pay link for a specific counterparty payment.
2. The link carries a signed token. It opens a mobile UPI-intent payment page for that one payment; the token grants access to nothing else.
3. You share the link directly or it is pinged to the counterparty over Telegram. They tap it on their phone to pay over UPI.

The link is meant to be opened in a mobile browser or shared inside a chat — it is not a developer endpoint you call from your own software, and we do not publish its URL structure, token format or any request/response schema.

04Webhooks & programmatic access

Webhooks, API keys and programmatic access are not available today. SQARME CMD does not expose outbound webhooks for order events, and there is no developer API key you can issue or use to drive the engine from your own code.

Event notifications today are delivered to you through the product itself — the live dashboard and Telegram alerts. If your workflow needs machine-readable events or a way to call the engine programmatically, that capability is on the roadmap (section 05), and we would like to hear your requirements.

To avoid confusion: any code-style examples we might add in future would describe real, shipped capabilities only. We do not publish placeholder endpoints. As an illustration of the conceptual difference, today you might share a link rather than call an endpoint:

# What exists today: a sharable One-Tap Pay link (conceptual — not a callable endpoint)
#   generated inside your dashboard, opened by a counterparty on mobile.

# What does NOT exist today: a programmatic call like
#   POST /v1/orders/{order_id}/release   <-- no such public API

The example above is illustrative only. No such public endpoint exists.

05Roadmap & early access

A public, scoped developer API is planned. The goal is a documented, permissioned interface that respects the same non-custodial, per-tenant security model described above — your credentials staying encrypted on your own isolated engine, with access gated and auditable.

We are not publishing endpoint paths, schemas, authentication details, rate limits or a release date yet, because none are finalised.We would rather ship something honest than promise specifics we cannot yet stand behind.

If a programmatic integration would help your desk, tell us what you need. Concrete use-cases directly shape what we build and who gets early access.