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 and documents for an order created with estamp-create-v1. Stamping is not instant — poll this until the order reports a terminal state, then download the stamped document. Priced at a nominal rate so polling is cheap, but poll sensibly (every few seconds, not in a tight loop).

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"`.

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.

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

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 OTP REQUIRED. Before pulling, capture the borrower’s consent via OTP: send an OTP to their mobile (see the Credit Consent OTP SMS API), have them confirm it, then pass that same OTP in the `otp` field as proof of consent. All six fields are mandatory: `mobile` (the number linked to the person’s credit record), `pan`, `name`, `gender` (`male`/`female`), `consent` (must be `"Y"`), and `otp`. The OTP must be UNIQUE per request — reusing an OTP for the same mobile is rejected upstream as an invalid OTP (422 INVALID_INPUT), which is the most common cause of failures on this endpoint. 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.

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.

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

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.

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.