API reference.

One key. Every venue. Every module. The reference below documents the wire-level contract of the capital markets platform — what you send, what you get back, what to do when things go wrong.

In build·Pre-production·API not yet callable·No production customers·No attestations held

Press ? for keyboard shortcuts

The API is organised around REST. Predictable resource URLs, JSON request bodies, conventional HTTP response codes, and a single envelope for errors. Streaming endpoints (market data, fills, audit events) are exposed over WebSocket and gRPC; the request shape is identical to the REST equivalent.

Every endpoint is tenant-scoped, MFA-enforced, idempotent where it matters, and audited. We document the entire surface — no private endpoints, no hidden parameters.

The shortest path from key to live order: a single POST to /v1/orders with an idempotency key. Pick the SDK you live in, or use the HTTP shape directly.

curl -X POST https://api.nexoratechnologiesnagpur.com/v1/orders \
  -H "Authorization: Bearer $NEXORA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "account":  "acc_SAMPLE01",
    "symbol":   "SAMPLE-EQ",
    "venue":    "NSE",
    "side":     "buy",
    "qty":      100,
    "type":     "limit",
    "price":    100.00,
    "tif":      "DAY"
  }'

Authenticate every request by setting an Authorization: Bearer $NEXORA_KEY header. Keys are tenant-scoped, scoped to a key role (read, trade, admin), and rotatable from the operations console. Compromised keys are revocable in seconds.

The order resource. Submit, modify, cancel, list. Every state change is logged to the append-only audit trail and surfaced via the order.* webhook family.

{
  "id":               "ord_SAMPLE01",
  "account":          "acc_SAMPLE01",
  "symbol":           "SAMPLE-EQ",
  "venue":            "NSE",
  "side":             "buy",
  "qty":              100,
  "filled_qty":       0,
  "type":             "limit",
  "price":            100.00,
  "avg_fill_price":   null,
  "tif":              "DAY",
  "status":           "accepted",
  "venue_order_id":   "NSE-SAMPLE-0001",
  "submitted_at":     "2026-05-19T09:31:14.118Z",
  "idempotency_key":  "f3e0c421-2c1f-4a8d-8c5b-9c0a1d9b3a44"
}

Pre-trade risk is invoked automatically on every order submission. The standalone risk endpoints exist for deterministic dry-runs — for example, calculating margin requirements before letting a user click "Buy".

Read-side projection over NSDL and CDSL. Holdings reflect T+1 settled stock plus T+0 pending. Reconciled with the depository every 30 minutes during market hours, and at EOD.

Realtime ticks, L2 depth, historical OHLC, and corporate actions. Streaming endpoints share the same parameters as their REST equivalents — pick the protocol that fits your latency budget.

import { Nexora } from "@nexora/sdk";

const nexora = new Nexora({ apiKey: process.env.NEXORA_KEY! });

// Subscribe to L2 depth across two venues, one stream.
const stream = nexora.marketdata.depth.subscribe({
  symbols: ["SAMPLE-EQ", "SAMPLE-FUT"],
  venues:  ["NSE", "BSE"],
  depth:   5,
});

for await (const tick of stream) {
  console.log(tick.symbol, tick.venue, tick.bids[0]?.px);
}

The compliance layer hosts the full KYC flow — PAN verification, Aadhaar eKYC, CKYC registry lookup, OCR + liveness. Your application creates a session and redirects the user to the hosted URL; we send a webhook when the verdict is final.

curl -X POST https://api.nexoratechnologiesnagpur.com/v1/kyc/sessions \
  -H "Authorization: Bearer $NEXORA_KEY" \
  -d '{
    "pan":       "AAAPL1234C",
    "redirect":  "https://yourapp.com/kyc/return",
    "level":     "investor",
    "consents":  ["aadhaar_ekyc", "ckyc_lookup"]
  }'

Sanctions, PEP and adverse-media screening. Synchronous for onboarding decisions; asynchronous for ongoing monitoring.

Every state change in the platform writes to a cryptographically-chained, append-only audit log with ten-year retention. Reports build on top of that log: regulator-ready exports, contract notes, and reconciliation trails.

Webhooks are the preferred way to react to state changes — fills, KYC verdicts, AML alerts, settlement events. Every delivery is signed; retries follow exponential backoff to 72 hours, with idempotent event ids.

{
  "id":          "evt_4qK9wRtN",
  "type":        "order.filled",
  "created":     "2026-05-19T09:31:18.521Z",
  "livemode":    true,
  "tenant":      "tnt_SAMPLE01",
  "data": {
    "id":             "ord_SAMPLE01",
    "status":         "filled",
    "filled_qty":     100,
    "avg_fill_price": 100.00,
    "fills": [
      { "px": 100.00, "qty": 60, "venue_ts": "2026-05-19T09:31:18.301Z" },
      { "px": 100.00, "qty": 40, "venue_ts": "2026-05-19T09:31:18.452Z" }
    ]
  }
}

The error envelope is the same on every endpoint. Conventional HTTP status, structured body, machine-parseable code, human- readable message, and a request_id you can hand to support.

{
  "error": {
    "type":    "invalid_request_error",
    "code":    "missing_required_field",
    "message": "Field 'qty' is required and must be a positive integer.",
    "param":   "qty",
    "request_id": "req_8mP2yLxV"
  }
}

Limits are per-tenant, not per-key. Each response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. When you exceed the bucket we return 429 and a Retry-After header.

We version the API surface, not the SDKs. Major versions live at distinct base paths (/v1, /v2) and run in parallel for at least 18 months after a new major ships. Within a major version we ship breaking changes behind request-header opt-ins, never silently.

Every write endpoint requires an Idempotency-Key header (UUID v4 recommended). The first request with a given key is processed normally; replays with the same key and same body return the original response without re- running the side-effect. Replays with the same key and a different body return 409.

Idempotency keys are scoped to a tenant and retained for 24 hours. That window is enough to recover from any network failure within the trading day; for longer durations, use aclient_order_id instead, which is permanent.