> ## Documentation Index > Fetch the complete documentation index at: https://docs.scripxhq.com/llms.txt > Use this file to discover all available pages before exploring further. # Terminology > Every term used in the ScripX API reference, defined for integrators: scrip, scroll, IEC, face value, balance, bps, all-in price, firm quote, price floor and ceiling, residual, cross and block deal, group netting, provenance, DvP, T+0, UTR, idempotency key, webhook signature and more, each with the API field that carries it. Every domain term the API reference uses, defined once. If a word on an endpoint page is unfamiliar, it is defined here, with the API field that carries it. For the wider market vocabulary an exporter or importer runs into outside the API, see the [Glossary](/concepts/glossary). ## The instrument ### Duty credit scrip A transferable electronic credit issued by the Government of India that pays **basic customs duty** at face value. Exporters earn them under RoDTEP and RoSCTL; importers spend them against duty on imports. Everything the API trades is a duty credit scrip. See [What is a scrip?](/what-is-a-scrip). ### e-scrip The electronic form the credit takes in the customs ledger once it has been created: a scrip number, a face value, a running balance and a validity date. Only an e-scrip can be transferred or used. ### Scrip number The identifier of one credit in the customs ledger. API field `scrip_no`. It is the key you quote against when you price one specific credit rather than an amount. ### Scroll The claim amount customs has sanctioned against filed shipping bills. A scroll is **not yet a scrip**: it is a sanctioned figure that must be converted into an e-scrip before it can be transferred or used. Credits appear on the API only after that conversion. ### Scheme Which remission scheme a credit was issued under. API field `scheme`, with exactly two values, `RODTEP` and `ROSCTL`. Each scheme is priced independently. See the [Schemes annexure](/annexure/schemes). ### Face value The duty-paying power of a credit, in rupees. API field `face_paise`, in integer paise. A credit with `face_paise: 100000000` settles ₹10,00,000 of duty. ### Balance The duty-paying power still remaining after any utilisation. API field `balance_paise`. A partly used credit is priced on balance, not on face. ### Validity and expiry The window in which a credit can be used or transferred. API field `expiry_date`. Validity runs one year from creation in the ledger and is unaffected by transfer; an unused balance at expiry lapses in full. See [Validity and expiry](/concepts/scrip-validity-expiry). ### Utilisation Applying a credit against duty payable on a Bill of Entry. Each utilisation reduces `balance_paise`. A credit ends at zero balance or at expiry. ## Parties and identifiers ### IEC Importer Exporter Code, the ten-character identifier issued by DGFT that every Indian importer and exporter trades under. It is the primary key for a firm across the whole API: firms are addressed as `/v1/firms/{iec}`, and crosses name `seller_iec` and `buyer_iec`. ### Firm A registered trading entity on your desk, addressed by its IEC. API field `role` is exactly one of `exporter` or `importer` per firm. ### Connection state Where a firm sits in onboarding. API field `state`, moving `verification_pending` to `connected`, with `reconnect_needed` when a connection lapses. **A firm trades only in `connected`.** See [Verify a firm](/api-reference/firms/verify). ### ICEGATE The Indian Customs Electronic Gateway, the CBIC portal where the e-scrip ledger lives. Scrip transfer and utilisation both happen there, which is why settlement is confirmed against it. See [Scrip transfer on ICEGATE](/concepts/scrip-transfer-icegate). ### Bill of Entry Abbreviated **BoE**. The customs document filed for an import, on which duty is assessed and paid. It is the point where a buyer applies scrips against duty. ### Basic customs duty Abbreviated **BCD**. The head of duty a scrip can pay. Scrips do not pay IGST on imports and do not pay most cesses and surcharges, which is what sizes an importer's real requirement. ### HSN 4907 The classification under which duty credit scrips fall for GST purposes. Scrip sales are GST-exempt under Notification 02/2017, so no GST sits on the scrip value in a transfer. This is why `all_in_paise` is the whole number. ## Money and price ### Paise Every money field on the API is an **integer number of paise** and ends in `_paise`. There are no floats and no currency field; everything is INR. `100000000` is ₹10,00,000. See [Money and price](/annexure/money-and-price). ### Basis point Abbreviated **bps**. One hundredth of a percentage point. Every price field ends in `_bps` and means basis points of face value: `10000` is 100.00% of face, `9650` is 96.50%. ### Discount The gap between face value and price, expressed as a share of face. A price of `9650` bps is a discount of 350 bps, or 3.50% of face. See [Price and discount explained](/concepts/scrip-price-discount). ### Scrip Reference Rate Abbreviated **SRR**. ScripX's published benchmark price for scrips, by scheme and expiry band, every trading day. Public and key-free at [`GET /public/rates`](/api-reference/public/rates), with the daily series at [`GET /public/rates/{scheme}/history`](/api-reference/public/rate-history). The SRR is a benchmark for information; a tradable number always comes from a firm quote. ### Firm quote A binding price for an exact credit or an exact requirement, good until a stated `valid_until`. Returned by [`POST /v1/quote`](/api-reference/trading/quote). Distinct from an **indicative** price, which is a view rather than something you can transact at. ### All-in price The single number that changes hands. API field `all_in_paise`. On a sell it is what the seller receives net; on a buy it is what the buyer pays in total. There is no fee schedule to add or subtract afterwards. ### Requirement The duty amount a buyer needs covered, passed as `requirement_paise` on a buy-side quote. The response reports `covered_paise` against it. ### Residual The part of a buy requirement that whole credits could not cover, because credits transfer whole and are never split. API field `residual_paise`; `fully_covered` is `true` when it is zero. The residual is settled in cash outside the trade. ### Price floor and ceiling Structural limits on an order that the match cannot cross. `min_pct_bps` is the seller's floor, below which a fill cannot happen; `max_pct_bps` is the buyer's ceiling, above which it cannot. Both are in bps of face. ### Savings On a buy-side quote, the cash gain versus paying the duty in full. API field `savings_paise`. ### Platform fee and net spread On the [cross desk](/api-reference/cross/quote), `platform_fee_paise` is ScripX's commission on the deal and `net_spread_paise` is what the desk keeps after it. Both are returned on the cross quote before anything is committed. ## Trading ### Order An instruction to trade a stated amount on a stated side, at or better than your limit. Created with [`POST /v1/orders`](/api-reference/trading/orders-create) and read with [`GET /v1/orders/{id}`](/api-reference/trading/orders-get). ### Batch Up to 500 orders submitted in one call with [`POST /v1/orders:batch`](/api-reference/trading/orders-batch). A batch does not fail wholesale: each item returns its own result. ### Position Your open and settled exposure, per scheme, with the cash side included. Read with [`GET /v1/positions`](/api-reference/trading/positions). ### Sellable The flag on a credit that says it has cleared [provenance screening](#provenance) and can be quoted and sold. API field `sellable`. Trade on this flag rather than inferring readiness from anything else. ### Provenance The screening a credit passes before it can be listed: its origin is traced to the shipping bill it derives from, the selling firm is KYC-verified, and the credit's title and status are confirmed live in the customs ledger. A credit showing `sellable: true` has passed. Buyers get provenance on every scrip without running the checks themselves. ### Cross, block deal A pre-arranged trade booked inside a desk's own book at prices the desk sets on both sides, rather than matched against the open market. `kind: "external"` is a brokered block between two unrelated firms; `kind: "intra_group"` moves credit between entities of one group. See the [cross desk](/api-reference/cross/create). ### RFQ The flag on a prepared cross that requires the counterparty to accept the terms before the deal can be funded. API field `rfq`. ### Group netting Squaring a group's companies against each other with the minimal set of internal transfers, so only the true group-level residual reaches the market. Computed by [`POST /v1/group/net-plan`](/api-reference/group/net-plan) from the book at [`GET /v1/group/positions`](/api-reference/group/positions). See the [enterprise guide](/guides/enterprise-group). ## Settlement ### Delivery versus payment Abbreviated **DvP**. Settlement where title and money move together, or neither moves. Buyer funds are locked before the credit transfers, and the seller payout fires on confirmation of the transfer. It removes the question of who goes first. A settlement that cannot complete unwinds and refunds in full. ### Settlement leg One side of a settlement: the **delivery leg** is the transfer of the credit on ICEGATE, the **payment leg** is the movement of cash. Under DvP the two legs complete together, so a partial outcome is not a state you have to handle. ### Same business day settlement Written **T+0**. On ScripX the seller payout fires on confirmation of the transfer, in minutes, on the same business day. ### UTR Unique Transaction Reference, the bank reference on a completed payout. It is the proof that money moved and the reconciliation key for a finance team. Carried on payout events and through to the [audit export](/api-reference/account/audit-export). ### IMPS Immediate Payment Service, the interbank rails used for seller payouts, which is what makes a same-day payout possible. ### Statement The itemised record for a period, including the running one. `mtd` is month to date. Read with [`GET /v1/statements/{period}`](/api-reference/account/statements). ### Audit export A tamper-evident, hash-chained export of your event log, verifiable offline by your auditor without contacting ScripX. See [`GET /v1/audit/export`](/api-reference/account/audit-export). ## API mechanics ### API key The credential on every authenticated request, sent as `X-ScripX-Key`. `scripx_live_…` is production, `scripx_test_…` is sandbox. Keys are shown once at issue. See [Authentication](/authentication). ### Child key A scoped key minted under your own key, typically one per service or sub-account, carrying a subset of your scopes and revocable on its own. See [Create an API key](/api-reference/keys/create). ### Scope The permission an endpoint demands of the key presented, such as `quote`, `orders:write` or `market:read`. A child key's scopes are always a subset of its parent's. The full table is in [Authentication](/authentication#scopes). ### Idempotency key The `Idempotency-Key` header on an order. Re-sending the same key returns the **original** order rather than creating a second one, so a retry after a timeout or a `429` can never double-place. One key per logical order, generated before the first attempt. See [Idempotency](/idempotency). ### Webhook A signed HTTP delivery of an event such as `order.matched`, `settlement.settled` or `payout.sent`. Registered with [`POST /v1/webhooks`](/api-reference/webhooks/register); the catalog is in the [Webhook events annexure](/annexure/webhook-events). ### Webhook signature The `X-ScripX-Signature` header, `sha256=` computed over the **exact body bytes** with your subscription's `whsec_` signing secret. Verify it before trusting a delivery, on the raw bytes and before any JSON parsing. See [Webhooks](/webhooks). ### Delivery id The `X-ScripX-Delivery` header, stable per event and subscription. Deliveries can repeat, so dedupe on this value. ### Dead-letter and replay A delivery that fails permanently, or exhausts its retries, is parked rather than dropped. List parked deliveries with [`GET /v1/webhooks/failures`](/api-reference/webhooks/failures) and push them again with [`POST /v1/webhooks/replay`](/api-reference/webhooks/replay). ### Cursor pagination Larger collections page with `limit` (default 100, maximum 500) and `cursor`, taking `next_cursor` from the previous response. Responses carry `count`, `total`, `next_cursor` and `has_more`. ### Request id The `X-Request-ID` header on every response, success or error, correlating one call to its server-side log line. Log it on every non-2xx and quote it in support. ### Error slug The stable machine-readable value you branch on, read as `code ?? error`. Never branch on `message`. The full vocabulary is in [Errors](/errors). ## Related * [Money and price](/annexure/money-and-price), the unit conventions with worked examples. * [Schemes](/annexure/schemes), the `scheme` enum and primary sources. * [Webhook events](/annexure/webhook-events), the event catalog. * [Glossary](/concepts/glossary), the wider market vocabulary.