How your credentials, your traffic and your record are handled

• Your broker credentials stay yours

  QuantGrid connects through your broker's official API using tokens you authorise. You can revoke access from your broker's console at any time, and the connection stops immediately.

  You authorise QuantGrid on the broker's own screen wherever the broker publishes one that QuantGrid uses, as Zerodha, Angel One, FYERS, Upstox, Nuvama Wealth, ICICI Direct, Dhan, Tradejini and IIFL do. What comes back is an API session token scoped to that broker's API. QuantGrid holds that token and the API key of the app you created with that broker and, where the broker issues one, its secret, encrypted; the key and secret are not enough to sign in as you, and QuantGrid never sees your password or second factor.

  Some brokers publish no login page at all. Groww, Motilal Oswal and Kotak are signed in from the credentials that broker's own login asks for plus a TOTP secret you supply, and Zerodha, Angel One, FYERS, Upstox, Nuvama Wealth, Dhan, Tradejini and IIFL can be signed in either way, so you choose. Where QuantGrid holds a TOTP secret it is encrypted at rest and used for nothing but that broker's own login.

  ICICI Direct is the opposite case and gets no automatic option at all: it publishes no unattended login, so a session there can only ever begin with a sign-in you complete yourself. Nothing beyond your own app's API key and, where the broker issues one, its secret, and the session token each sign-in returns, is stored for it, and the key and secret are not enough to sign in as you.

  QuantGrid uses a broker session for one day at most: until the broker's own daily cut-off or, where a broker publishes none, until midnight IST. None of them can be refreshed without signing in again.

• A static IP reserved to you alone

  Every broker account you connect gets a dedicated static IP address that is never shared with another customer. Brokers that require API access from a whitelisted IP will see one stable address, and your API activity is never mixed with anyone else's.

  The address is allocated to your account and stays the same across restarts, redeploys and reconnects. Everything QuantGrid does on your behalf leaves from it: the authorisation call, the order WebSocket subscription, the REST order-book polls and every child order placement.

  If your broker asks you to declare or whitelist the address your API calls come from, you enter one value, once. No other customer's traffic ever originates from it.

• Encryption in transit and at rest

  All traffic runs over TLS. Broker tokens and account secrets are encrypted at rest and are never written to application logs.

  Broker traffic is HTTPS and WSS only, with no plaintext fallback path. Tokens and account secrets are encrypted before they reach the database, and the fields holding them are excluded from application log output.

  Some broker socket handshakes carry the access token inside the connection URL. Rather than record that request and redact it afterwards, the telemetry pipeline drops WebSocket handshake events entirely, so the token never lands in a monitoring system in the first place.

• Tenant isolation

  Each account's data is bound to its own tenant at the point where a broker stream is opened, so one customer's order events can never reach another customer's replication engine.

  The owning account is attached at the moment a broker stream is opened, not looked up later. That identity travels with the event through normalisation, the in-process event bus and job creation, so there is no stage where an event exists without knowing whose it is.

  Broker accounts carry an owner as a database foreign key, and a copy relationship can only be created between accounts under the same login. It is a constraint in the schema, not a check in the interface.

• Duplicate-order protection

  Every replicated order passes three independent duplicate checks before it reaches a broker. A network retry, a reconnect or a repeated event cannot place the same child order twice.

  The three layers are independent by design. A marker key in Redis short-circuits an event that has already been handled. A distributed lock, held per child account and instrument, stops two workers racing on the same fill. A unique database index on the idempotency key is the final backstop.

  The first two exist for speed. The third exists for correctness: if the database refuses the insert, no order is sent to the broker.

• Complete audit trail

  Every event received, every decision taken and every broker response is written to an append-only log. Your dashboard shows the decisions and alerts on the Logs page and every order on the Orders page, and support can walk you through the full record of any order.

  Order events are written before replication is attempted, each stamped with the path that delivered it (websocket or rest_poll), so you can tell a live socket update apart from one recovered by order-book polling.

  Every replication job records the quantity it calculated, the multiplier and lot size it used, the broker's response, and the reason when nothing was sent, including the case where a multiplier floors below one full lot. Records are appended, never edited after the fact.

The scope of that token is the broker’s to define, not ours. What it permits, and what it does not, is described in each broker’s API documentation, which we link from the supported brokers pages.