Developer Documentation

List the stamp articles available for a state, with the `articleId` you must quote when creating an order. Call this FIRST. An article is the head of charge under the state Stamp Act (Simple Agreement, Affidavit, Works Contract, Power of Attorney, and so on), and `articleId` values are state-specific — an id valid in Rajasthan is not valid in Maharashtra. Creating an order with a mismatched article is rejected. The full catalogue is large (1600+ rows across states); filter client-side on `stateCode` for the state you are stamping in. Reference lookup, priced at a nominal rate.

Create an electronic stamp-paper order. Returns an `order_id` you then poll with estamp-status-v1 for the stamped document. BILLING — read this before integrating. Two separate amounts are charged for one call: 1. A flat service fee per order (the price shown for this product). 2. The STAMP DUTY itself, which is passed through to the state at cost — the total of every `stampDutyAmount` in `series`. For a Rajasthan stamp (`stateCode: "RJ"`) the state levies a 30% surcharge on the duty, which is added automatically. The surcharge follows the STAMP, not your billing address: a Maharashtra-registered company stamping in Rajasthan pays it. So a Rajasthan order with 5000 duty is charged: service fee + 6500 duty. Make sure your wallet covers both, or the call returns 402 INSUFFICIENT_BALANCE before anything is created. `refId` must be unique per order (use your loan account number or similar) — a repeat is rejected, which makes retries safe. `articleId` comes from estamp-articles-v1 and must be valid for your `stateCode`.

Fetch the current status of an order created with estamp-create-v1, and the stamped certificate once it is issued. WHERE THE CERTIFICATE IS. When `data.status` is FULFILLED (or CONSUMED), the certificate PDF link is `data.stampCertificateUrl` and its id is `data.eStampId`. Each stamp is also listed in `data.orderItems[]` with its own `certificateNo`, `eStampId` and `stampCertificateUrl`. There is no separate documents array. The top-level `status` is only a message; the order status is `data.status`. THE LINK EXPIRES. `stampCertificateUrl` is a time-limited link: download the PDF and store it in your own system as soon as the order is FULFILLED. To get a fresh link later, call this API again. TEST MODE returns a FULFILLED order whose link opens a sample certificate marked SAMPLE - NOT VALID, so you can build and test the download step. Stamping is not instant: poll every few seconds (not in a tight loop) while `data.status` is IN_PROGRESS. Priced at a nominal rate so polling is cheap.

Fetch the current status of a signing request created with esign-create-v1, and once signed, the signed PDF plus the signer verification details. PASS THE PER-SIGNER `request_id`, NOT THE GROUP ID. esign-create-v1 returns one `request_id` per signer inside `requests[]`, plus a single `group_id` for the envelope. This endpoint takes the per-signer id; the group id returns 404. For a two-party document you poll twice, once per signer. THE SIGNED URL EXPIRES IN 24 HOURS. `signed_url` is a time-limited link, not permanent storage. Download the PDF and store it in your own system as soon as `signed` is true — do not persist the URL and expect it to work tomorrow. EVIDENCE ARTEFACT: for an Aadhaar signature the response carries `verified_name` (the name held against the Aadhaar record), `name_match_score` (0-1, how closely it matches the name you supplied) and `certifying_authority` (the licensed CA that issued the signature). Together with the signed PDF these are what make the signature defensible under §3A of the IT Act. A low `name_match_score` on an otherwise SUCCESSful signature is worth reviewing before you rely on the document. Polling: signing happens after esign-create-v1 returns, so poll this until `signed` is true or the request expires (`expires_at`, 7 days by default). Priced at a nominal rate so polling is cheap, but poll sensibly — every few seconds, not in a tight loop.

Send a PDF for legally-valid electronic signature under the IT Act. PRICING IS PER SIGNATORY, not per request. One call can carry several signers, and each is a separate signing transaction — its own request_id, its own invitation, its own Aadhaar/DSC authentication. The price shown is the rate for ONE signatory; a request is billed at that rate × the number of entries in `signers`. A two-party NDA therefore costs twice the listed rate. Your wallet must cover the full amount before the request is created, or the call returns 402 INSUFFICIENT_BALANCE and nothing is sent. Each signer gets their own `signing_url` and authenticates by Aadhaar OTP, WhatsApp or auto-DSC (`signer_auth_type`). You receive a `group_id` for the whole envelope and a per-signer `request_id`. INVITES ARE SENT FOR YOU. Each signer is emailed/messaged a signing invitation automatically, and the response reports `invitation_status` per signer. You also receive a `signing_url` per signer, so you can additionally surface the link in your own UI if you prefer — but you do not have to deliver it for signing to happen. COMPLETION. Signing happens after this call returns, so the response tells you the request was created, NOT that anything is signed. Track completion by polling, or register a callback and treat it as a prompt to re-check rather than as proof — never release a document on the strength of an unverified callback alone. `sign_coordinates` places the signature block on the page (x/y/page_num). Omit it to use the provider default position.

Start a consented Aadhaar verification. Returns a `kyc_url` — send your customer there and they authenticate with UIDAI directly, entering their Aadhaar number and OTP on the government screen. YOU NEVER SEE THE AADHAAR NUMBER OR THE OTP. That is the difference between this and raw OKYC, and it is why this flow is usually the easier one to get signed off internally. What you get back at the end is a masked Aadhaar number plus the verified demographics. TWO STEPS, TWO CALLS. This one issues the link. Once the customer finishes, call aadhaar-digilocker-fetch-v1 with the `transaction_id` returned here to collect the result. Store that id against your application record — without it you cannot retrieve the verification. `uid` is YOUR reference and must be unique. A repeat is rejected, which is what makes retries safe. Supply `mobile` or `emailId` (at least one); `redirectionUrl` is where the customer lands afterwards, and receives `txnId` plus either `success=true` or `error_code` and `errMsg`. Billed per link issued. The verification itself is billed on the fetch call.

Collect the verified record once your customer has completed DigiLocker. Call it with the `transaction_id` from aadhaar-digilocker-init-v1. THE AADHAAR NUMBER IS MASKED and always will be — the full number is never returned by this flow. You receive name, date of birth, gender, care-of, a structured address and a base64 photo. POLL, DO NOT ASSUME. Until the customer finishes, this returns 422 with "The given transaction id for digilocker is not success". That is normal and is not an error on your side — it means they have not completed the UIDAI screens yet. Poll after your redirect fires, or on a sensible interval. Three outcomes are the CUSTOMER’s and not a fault: they declined consent, their DigiLocker account holds no eAadhaar, or they did not select the Aadhaar document. Treat those as a failed verification rather than a retryable error.

One call that turns a lead into a profile. Send a mobile number — and a PAN if you have one — and we run the relevant lookups across the catalogue and return a single merged result: employment, GST, MSME, directorships and company. THE SECOND HOP IS THE POINT. Identifiers discovered in the first pass are followed automatically: a DIN found from the PAN fetches director details, a CIN fetches company master data. You never round-trip to chase them yourself. PRICING IS NOT FIXED — READ THIS BEFORE BUDGETING. You pay the normal price of each sub-lookup that SUCCEEDED, and nothing for the ones that failed or were skipped. There is no separate orchestration fee. The price shown on this page is the basic-tier FLOOR; a full-tier call on a rich lead costs considerably more. Every response itemises each lookup and what it cost in `lookups[]`, and `totalSalePaise` is exactly what you were billed — so every invoice line traces back to a lookup. WHAT COUNTS AS BILLABLE: a lookup that returns a definitive "no record" IS billed — the source did the work, and `verified: false` is still information. A lookup that FAILED (upstream error) or was SKIPPED (you did not supply the input, or that source is unavailable) costs nothing. TIMING: basic returns in 1-3s. Full includes the MSME lookup, which is currently slow (24-27s), so set your client timeout to at least 45 seconds for `tier: "full"`.

Masked PAN linked to input Aadhaar number

Validate DL with additional details

Verifies a driving licence against the Sarathi (transport department) record: holder name, date of birth, validity dates, licence classes and issuing authority. INPUT FORMAT: send `dl_number` exactly as printed but with no spaces or hyphens (e.g. RJ1420110012345), and `dob` as DD/MM/YYYY (e.g. 15/01/1990). Any other date format is rejected with 400 INVALID_REQUEST. Note that dates in the RESPONSE (dob, valid_from, valid_upto) come back as YYYY-MM-DD; that is the output format only. NOT FOUND: 404 NOT_FOUND means the source has no licence matching that number AND date of birth (usually a wrong date of birth or a typo in the number). It is not a configuration problem and it is NOT charged. Every response, including errors, carries an X-Call-Id header: quote it to support.

Resolve an IFSC code to its bank, branch, address and payment-rail support.

Score how likely two spellings of a name belong to the same person, from 0 to 100. Built for Indian KYC records: it ignores case, punctuation, titles (Mr, Smt, Dr, Shri) and word order, understands initials (R Kumar / Ravi Kumar), joined names (Vijaykumar / Vijay Kumar), common abbreviations (Mohd / Mohammed, Kr / Kumar) and spelling variants (Preeti / Priti, Rafiq / Rafik). A missing middle name costs a little; a different first name costs a lot. Returns the score, a match flag at your threshold (default 80) and the kind of match.

Check that Indian identifiers are well-formed before you pay for a lookup: PAN, GSTIN (with check character), Aadhaar (Verhoeff check digit), Aadhaar VID, IFSC, mobile, email, UPI ID, CIN, LLPIN, DIN, TAN, Udyam, Voter ID, passport, driving licence and vehicle registration. Send any combination in one call. Each comes back valid or not, with the reason and what its structure tells you (PAN holder type, GSTIN state and embedded PAN, CIN company type and year). This checks format only, not whether the number exists. A full Aadhaar number is never echoed back.

Look up an Indian pincode and get its district, state, postal division and circle, every post office it covers (head, sub and branch offices, with delivery status) and map coordinates where India Post publishes them. Data: India Post's All India Pincode Directory. Use it to auto-fill addresses and to check that a customer's pincode matches their stated city and state. A pincode India Post does not list returns 404 and is not charged.

Convert between map coordinates and India Post's DIGIPIN, the 10-character code for a roughly 4m x 4m square anywhere in India. Send latitude and longitude to get the DIGIPIN, or a DIGIPIN to get its location. Either way you also get the nearest post office and its pincode, so a captured GPS point becomes a postal address hint. Uses India Post's official open algorithm. Nearest office is approximate: it is the closest office India Post publishes coordinates for, not the postal boundary.

Look up a Legal Entity Identifier (LEI) in the Global LEI Index, by LEI, by company registration number (CIN or LLPIN) or by company name. Returns the legal name, registration number, legal and head-office address, entity status, and whether the LEI is currently valid for regulatory use (ISSUED) or has lapsed. RBI requires an LEI for large-value payments and for borrowers above set exposure limits. Name searches return up to 10 entities ranked by how closely the name matches.

Check an email address without sending it anything: is the format valid, does the domain accept mail (MX record), is it a throwaway / disposable address (about 9,800 known domains), a free provider like Gmail, or a role address like info@ or sales@. deliverable is true when the domain can receive mail and nothing marks the address as junk. It does not confirm that the individual mailbox exists.

Find the right HSN code for goods or SAC code for services, or look up what a code means. Send code to get its description, its place in the tariff (chapter, heading, sub-heading) and the codes under it. Send query to search by plain words: everyday terms like laptop, saree or t-shirt are mapped to the official tariff wording. Data: the GST portal's HSN/SAC master. This returns codes and descriptions only, not GST rates.

Screen a person or company name against the UN Security Council Consolidated List, the US OFAC SDN list and the EU Consolidated Financial Sanctions List in one call. Lists are refreshed from the official sources every 6 hours. Matching understands spelling variants, initials, word order and aliases. Pass dob to rank hits with the same birth year first and to set aside same-name hits with a different birth year. result is possible_match when at least one hit is not ruled out by date of birth: send those for manual review. A hit is never proof on its own.

A complete business profile from one PAN, in one call: the PAN holder (name, type, status, address), every GST registration under the PAN with full details (status, constitution, turnover slab, nature of business, latest returns) for the active ones, the company's MCA record (CIN, status, capital, industry, registered address, active directors, registered charges), director identification for individual PANs, and the Legal Entity Identifier (LEI). Pass include_report: true to also get a ready-to-share PDF report. Company and LLP PANs get the MCA record; individual PANs get their director record if they hold a DIN. Parts that a registry has no record of come back empty rather than failing the call. Charged once per call, only when the PAN is found; a PAN with no record anywhere returns 404 and is not charged.

PAN + Aadhaar input -> linked Yes/No

Validate PAN and obtain name associated with PAN

PAN details V1 plus salaried/self-employed indicator and PAN issue date

Verify a PAN against the government source. Returns verified flag, name, DOB, gender, Aadhaar-link flag, category (holder type) and address. Send a REAL, well-formed PAN. A structurally invalid or non-existent PAN (e.g. a placeholder like "ABCDE1234F" — the 4th letter must be a valid holder-type code such as P for individual) returns 422 INVALID_INPUT, not a result. Billed on SUCCESS only — invalid/no-record lookups are NOT charged.

Father's name from PAN

Returns whether a PAN is linked to an Aadhaar and the masked Aadhaar number seeded against it (first 2 and last 2 digits visible, e.g. 12XXXXXXXX34), without the holder entering Aadhaar or an OTP. The full Aadhaar number is never returned: under the Aadhaar Act only the holder may share it. To check a full number your customer gives you, use pan-aadhaar-link (verifies it, never reveals it). For verified Aadhaar details with consent, use DigiLocker (aadhaar-digilocker-init-v1 / aadhaar-digilocker-fetch-v1). Individual PANs only; a company PAN has no Aadhaar.

Validate passport via file number and get details

Fetch RC (Registration Certificate) details for a vehicle from VAHAN.

Verify a Voter ID (EPIC) number against the Election Commission source.

Confirms a PAN exists and is active, with the registered name. The cheapest PAN check — use it when you only need existence and status. Use PAN Verification for date of birth and holder category, or PAN Details Plus for the full profile. Billed on success only; a PAN with no record is not charged.

The full PAN profile in one call: name parts, date of birth, gender, PAN type and status, allotment date, Aadhaar-linked flag with the masked Aadhaar, registered address, email and mobile on record, and whether the holder is a company director, salaried, or a sole proprietor. Built for underwriting: one call answers most of a KYC form. For a company PAN, `dob` is the date of incorporation and `signatory_details` lists the authorised signatories.

Whether a PAN is linked to the given Aadhaar. Returns a definitive answer either way — `linked: true` or `linked: false` — and both are billed, because both are answers. Individual PANs only: a company PAN has no Aadhaar and is rejected with a clear message (422, not charged).

Verifies an EPIC (voter ID) number against the Election Commission record and returns the registered name, relation, gender, age, state, district and constituency. No record found returns 404 and is not charged. Names on the electoral roll are often spelled differently from PAN/Aadhaar — match with tolerance.

Everything in Driving Licence Verification plus the holder photo, a split address (house, street, city, district, state, pincode), badge details and the last-transaction date — the version to use when the licence is the primary KYC document. Same inputs.

Verifies a passport application against the Passport Seva record using the file number and date of birth: given name, surname, masked passport number, application type and key dates. The file number is on the application receipt (e.g. GZ1012345678912); date of birth as DD/MM/YYYY. No record returns 404 and is not charged.

Returns the masked PAN linked to an Aadhaar number and whether a link exists — the reverse of PAN to Masked Aadhaar. No OTP. Use it to pre-fill PAN when only Aadhaar is known. Not charged when nothing is linked.

Returns the father's name registered against an individual PAN, masked as the source provides it. Used for name-match and KYC form pre-fill. Individual PANs only (4th character P).

Whether a PAN has filed income-tax returns, and for which assessment years — acknowledgement number and date per year, with form and filing type where the source has them. A quick income-compliance check for lending and vendor onboarding: no OTP, no consent flow, no document upload. Both outcomes are answers and both are billed: `has_filings: true` with the list, or `has_filings: false` when the PAN has never filed.

Consent-based CIBIL (TransUnion) credit report and score for an individual, looked up by PAN + mobile. Returns the bureau score plus the structured credit report (accounts, enquiries). CONSENT REQUIRED. You must hold the borrower’s consent for the credit pull before calling, and keep it as evidence. How you collect it is up to you: an OTP (see the Credit Consent OTP SMS API), a signed / e-signed loan application, or a recorded checkbox with timestamp. Mandatory fields: `mobile` (the number linked to the person’s credit record), `pan`, `name`, `gender` (`male`/`female`) and `consent` (must be `"Y"`). Optional: `consent_reference` (your application / e-sign / consent-log id, stored with the call as evidence) and `otp` (if you collected consent by OTP). Billed on SUCCESS only. (A downloadable-PDF variant is available separately as CIBIL Credit Report (PDF).) TIMING: bureau pulls are slow — typical 4-9s, p95 ~8.5s. Our upstream timeout is 15s, so set your client timeout to at least 20s. A client timeout below ~10s will surface as a failure on your side for calls we complete successfully. Timeouts are never charged.

Consumer credit report from Experian, pulled by mobile number with explicit borrower consent. SINGLE CALL — there is NO separate "send OTP" / OTP-initiation endpoint. The consent OTP is handled at YOUR end: send an OTP to the borrower’s registered mobile using your own OTP/SMS system, have them confirm it, then pass that same OTP here (in the `otp` field) as proof of consent. The OTP must be UNIQUE per request — reusing the same OTP for the same mobile is rejected as an invalid OTP. `device_type` and the internal name-lookup flag are set by API Sathi server-side, so you do not send them. Billed on SUCCESS only: a rejected OTP / device_ip / consent / timestamp returns a 4xx and is NOT charged. TIMING: bureau pulls are slow — typical 4-9s, p95 ~8.5s. Our upstream timeout is 15s, so set your client timeout to at least 20s. A client timeout below ~10s will surface as a failure on your side for calls we complete successfully. Timeouts are never charged. OPTIONAL FIELDS: `pan`, `date_of_birth` (YYYY-MM-DD) and `email` improve the bureau match; send them in the request BODY (never in headers). `report_type` adds a PDF and/or XML of the report: "3" = JSON + PDF link, "4" = JSON + PDF + XML links. The links expire after 1 hour, so download and store the file straight away. RESPONSE: the score is at `credit_score`; the full Experian report is at `report.result_json.INProfileResponse` (accounts in CAIS_Account, enquiries in CAPS). The layout is the Experian bureau format, so it differs from the CIBIL report. `result_code` 102 = no record at the bureau, 103 = name not found for this mobile, 106 = mobile not authenticated by the bureau.

Consumer credit report and score for an individual, pulled by mobile number with explicit borrower consent. SINGLE CALL — there is NO separate "send OTP" endpoint. The consent OTP is handled at YOUR end: send an OTP to the borrower’s registered mobile using your own OTP/SMS system (see the Credit Consent OTP SMS API), have them confirm it, then pass that same OTP here as proof of consent. The OTP must be UNIQUE per request. Billed on SUCCESS only (a successful pull includes the "no record found" case). TIMING: bureau pulls are slow — typical 4-9s, p95 ~8.5s. Our upstream timeout is 15s, so set your client timeout to at least 20s. A client timeout below ~10s will surface as a failure on your side for calls we complete successfully. Timeouts are never charged.

Check IT returns filed last 3 FY with type and ack number

Credit report against a masked mobile number with consent (Experian, via API Sathi).

Alternate mobile + likely current addresses post disbursal

Locate and profile a borrower from a PAN or mobile number: current and historical addresses, alternate mobiles and emails, employment and business profile, bank and UPI presence, social footprint — each section with its own confidence and source status. Built for collections and field-verification teams. Supply `pan` or `mobile` (at least one); `name` improves matching. Sections the sources cannot resolve come back empty with `metadata.<section>.status` explaining why, and the call is still billed — it is a search, not a lookup.

Validate a company CIN and fetch enriched MCA master data, directors and charges.

Validate a company CIN and fetch master company data from MCA.

Deep MCA company profile for a CIN: master data, directors, charges and signatories.

Resolve the company PAN linked to a CIN.

Resolve candidate CINs for a company name with match scores.

Resolve candidate company PANs for a company name with match scores.

Find GSTINs linked to a mobile number with legal/trade names.

Validate a Director Identification Number and return director name and status.

Resolve the PAN linked to a Director Identification Number (DIN).

Enhanced GSTIN intelligence: taxpayer details, contacts, business nature PLUS the full GST return filing history (GSTR1 / GSTR3B / GSTR9 / GSTR9C) with filing dates, status, delayed flag and return-filing frequency. Use this to fetch a business’s GST returns.

Authenticate a GSTIN and return taxpayer details, return filings and places of business.

Authenticate a GSTIN and return core taxpayer details.

List all GSTINs registered against a PAN, optionally filtered by state.

Fetch the registered mobile and email contact for a GSTIN.

Find Udyam (MSME) registrations linked to a mobile number. SLOW BY DESIGN — SET A LONG TIMEOUT. This endpoint takes 24-27 seconds against a source that is currently degraded; measured 24.5s and 26.3s on consecutive live calls. Set your client timeout to at least 45 seconds. A 30-second client timeout WILL fail intermittently on this product even though the call succeeds on our side, and you will be charged for a result you never see. Every other product in the catalogue returns in a few seconds; this one is the exception.

Resolve the company CIN and basics (name, status, incorporation date) linked to a COMPANY PAN. Requires a company/entity PAN — the 4th letter must be C, F, H, A, T etc., NOT an individual PAN (P). An individual or unrecognized PAN returns 422 INVALID_INPUT (a company has no CIN). Billed on success only.

Resolve the Director Identification Number (DIN) linked to a PAN.

Look up TANs registered against a company name with match scores.

Validate a TAN and fetch the associated company name, status and address.

Cancel an e-way bill that was generated through the e-invoice system. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Cancel a registered IRN within the window the portal permits. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Decode the signed QR payload on an e-invoice and return its contents in readable form. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Decode the signed invoice payload returned at IRN generation. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Raise an e-way bill directly against an already-registered IRN, without re-keying the invoice. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Register an invoice carrying up to 1000 line items. Same contract as Generate IRN, sized for bulk documents. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Register an invoice and obtain its IRN, signed QR code and acknowledgement. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Render a signed QR payload as an image for printing on the invoice. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Fetch a registered e-invoice using its acknowledgement number. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Fetch a registered e-invoice using its IRN. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Fetch the e-way bill details attached to a registered IRN. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Find the IRN for an invoice from its document type, number and date. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Retrieve a previously generated QR image. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Check whether a GSTIN is enabled for e-invoicing and fetch its registered details. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Refresh a GSTIN's details from the GST common portal when the e-invoice system holds stale data. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Cancel an e-way bill you generated. Only permitted within the window the portal allows and before verification in transit. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Close an e-way bill so it can no longer be acted on. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Extend validity on a consignment still in transit. Allowed only inside the portal's permitted window around expiry. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Combine several e-way bills moving on one vehicle into a single consolidated bill (trip sheet). CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Generate an e-way bill for a consignment. Returns the EWB number and validity. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

List the e-way bills you generated on a given date. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Find the e-way bill generated against a specific consignor document. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

List e-way bills other parties have raised against your GSTIN. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Fetch a consolidated e-way bill (trip sheet) and the bills it covers. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

The portal's current error-code list, useful for mapping rejection reasons to messages. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

As a transporter, list the e-way bills assigned to you for a given day. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

As a transporter, list the e-way bills assigned to you by a particular GSTIN. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Resolve an HSN code to its official description. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

List your e-way bills that the counterparty has rejected. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Look up a taxpayer's registration details as the e-way bill system holds them. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

As a transporter, list assigned e-way bills filtered by state. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Look up a transporter enrolled on the e-way bill system by their transporter ID. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Fetch a single e-way bill by its number, with full Part-A and Part-B detail. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Add vehicle details to an initiated multi-vehicle movement. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Change vehicle details already recorded against a multi-vehicle movement. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Start a multi-vehicle movement for a single e-way bill, where one consignment is split across vehicles. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Re-issue a consolidated e-way bill (trip sheet), typically after a vehicle change. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Reject an e-way bill raised against your GSTIN by another party. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Transporter-assigned e-way bill report for a given assignment date. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. PARAMETERS ARE RELAYED VERBATIM. Put the portal’s documented query parameters in `query_string` exactly as the portal names them — they are case-sensitive and we do not rewrite them. THE SAMPLE BELOW IS ILLUSTRATIVE unless noted. Two parameter names are confirmed against the live portal: `GSTIN=` on the taxpayer lookup (upper case) and `hsncode=` on the HSN lookup (lower case) — the portal is inconsistent about casing, which is why we relay rather than normalise. For every other read, check the portal specification; if a parameter is rejected, the portal names the one it wanted and we will correct the sample.

Attach or change the vehicle and transport details (Part-B) on an existing e-way bill. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Reassign an e-way bill to a different transporter GSTIN. CREDENTIALS ARE THE TAXPAYER’S, AND ARE PER CALL. `gstin`, `username` and `password` are the credentials the GST portal issued to that taxpayer for API access — not an API Sathi login. They are sent per request rather than stored against your account, because one customer legitimately files for several GSTINs. They are write-only: they never appear in your call history or in our logs. DO NOT SEND A REQUEST ID. The portal requires a unique id on every request. We mint it from the call id, so it is guaranteed unique and it ties your call to our trace and the portal’s record — one identifier for a support conversation. A `request_id` you send is ignored. FAILURE IS NOT CHARGED. The portal reports a rejection in its own body rather than as an HTTP error — a wrong credential, an expired e-way bill, a duplicate document. We surface it as an error with the portal’s reason, release the wallet hold, and you are not billed. You pay for calls the portal accepted. READING A 502. A `VENDOR_ERROR` carries the portal’s own words in `reason`, and the wording tells you where the problem is. “Invalid login credentials” or “Incorrect user id” means the taxpayer’s `username`/`password` — not your API Sathi key, and not our platform. Those are issued by the GST portal to that GSTIN and must be enabled for API access there. Anything mentioning a header, an action or a mandatory parameter is ours: send it to us with the call id and we will fix the mapping. THE BODY IS RELAYED VERBATIM. Send the portal’s documented request body as `payload` and we pass it through untouched. Consult the e-way bill / e-invoice API specification for the fields this operation expects; the sample below shows the envelope, not the body.

Employment lookup by mobile number, with EPFO passbook for the last 3 months. A MOBILE MATCHING MANY RECORDS IS CURRENTLY AN ERROR, NOT A RESULT. If the number is linked to more records than the source will return, the call fails with 502 VENDOR_ERROR and the reason “Too many responses” rather than a list. That is a definitive outcome — retrying will not help. Treat it as “narrow the query” and, where you can, use a more specific lookup. We are reviewing this classification with the source and expect to return it as a normal response rather than an error.

Employment history since 2012 by mobile number, with EPFO passbook for the last 3 months. A MOBILE MATCHING MANY RECORDS IS CURRENTLY AN ERROR, NOT A RESULT. If the number is linked to more records than the source will return, the call fails with 502 VENDOR_ERROR and the reason “Too many responses” rather than a list. That is a definitive outcome — retrying will not help. Treat it as “narrow the query” and, where you can, use a more specific lookup. We are reviewing this classification with the source and expect to return it as a normal response rather than an error.

Latest employment lookup by mobile number (UAN + current employer). A MOBILE MATCHING MANY RECORDS IS CURRENTLY AN ERROR, NOT A RESULT. If the number is linked to more records than the source will return, the call fails with 502 VENDOR_ERROR and the reason “Too many responses” rather than a list. That is a definitive outcome — retrying will not help. Treat it as “narrow the query” and, where you can, use a more specific lookup. We are reviewing this classification with the source and expect to return it as a normal response rather than an error.

Employment history since 2012 by mobile number (UAN + employers). A MOBILE MATCHING MANY RECORDS IS CURRENTLY AN ERROR, NOT A RESULT. If the number is linked to more records than the source will return, the call fails with 502 VENDOR_ERROR and the reason “Too many responses” rather than a list. That is a definitive outcome — retrying will not help. Treat it as “narrow the query” and, where you can, use a more specific lookup. We are reviewing this classification with the source and expect to return it as a normal response rather than an error.

Send a loan-eligibility / credit-rating CONSENT OTP by SMS on a DLT-approved template. Pass the OTP you generated as `variables.otp` — the message wording and DLT template are fixed server-side (you do NOT choose the text). This is one of a family of purpose-specific SMS APIs — to send a different message, call the API for that message type (e.g. `sms-credit-consent-v1` for an Experian credit-report consent OTP). Charged per SMS on success.

Send a borrower a credit-report (Experian) CONSENT OTP by SMS on a DLT-approved template. Use this to capture consent before a `credit-report-v1` pull: send the OTP here, have the borrower read it back, then pass that same OTP to `credit-report-v1`. The message wording and DLT template are fixed server-side; you only supply the OTP value. The OTP is stated valid for 10 minutes in the message. Charged per SMS on success.

Pending traffic e-Challan details for a vehicle registration (RC) number, sourced from VAHAN/Parivahan. Returns the list of challans and a total count; a vehicle with no pending challans returns echallan_count 0.

Lock a financed handset remotely. Built for device finance and phone EMI: when a borrower defaults, the handset is restricted until they pay. THE HANDSET MUST BE ENROLLED FIRST. Locking works against a `key_id` issued when the device was enrolled and provisioned with the on-device agent. You cannot lock an arbitrary phone by IMEI — enrolment happens at the point of sale, or on a device the borrower hands over for provisioning. LOCKING IS ASYNCHRONOUS. A 200 means the instruction was accepted, not that the screen is already locked — the handset applies it when it next reaches the network. The response carries `state` (PENDING or COMPLETE). Confirm with device-control-status-v1 rather than assuming; a phone that is switched off or out of coverage will report PENDING for as long as it stays that way. Use device-unlock-v1 to release. Every action is recorded in device-action-history-v1, which is the audit trail you will want in a dispute.

Release a locked handset. Same asynchronous behaviour as device-lock-v1 — a 200 means the instruction was accepted, not that the borrower can already use the phone. CONFIRM BEFORE YOU TELL THE CUSTOMER. Poll device-control-status-v1 until the LOCK control reads unlocked. Telling a borrower their phone is unlocked while it is still restricted is the single most common support complaint on device finance, and it is avoidable.

The current on/off state of every control on an enrolled handset, including the handset lock. This is how you confirm a lock or unlock actually landed, since both are applied asynchronously. Returns one entry per control with `name` and `action_status`. The handset lock is the entry named LOCK.

Every control action ever applied to a handset, with status and timestamps. This is the audit trail for disputes — it shows who locked what and when, and whether each instruction completed.

List the handsets enrolled under your account with their key ids and status. Use it to recover a `key_id` you did not store against your loan record. Reference lookup, priced at a nominal rate.