Skip to main content
Vendor Taxation Creation API

Authentication

All requests require an API key in the request headers. Headers:

Request

Content-Type: application/json Adds a tax identifier to a vendor that already exists. The identifier being added is selected by the type query parameter — a GSTIN or a PAN — and its value is sent in the body. A vendor can hold multiple GSTINs (one per state), as long as every GSTIN belongs to the same PAN. A PAN on the other hand is a single-value fallback for vendors without GST registration: it can only be added while the vendor has no GSTIN and no PAN at all. Use the Vendor Details API to check what the vendor currently holds before calling. To change a value that already exists, use the Vendor Taxation Update API instead — this endpoint never overwrites an existing identifier.

Path Parameters

Query Parameters

Body Parameters

Unknown properties are rejected with 400 VALIDATION_ERROR — they are not silently ignored.
Values are matched case-sensitively against upper-case formats. Send 29ABCDE1234F1Z5, not 29abcde1234f1z5 — a lower-case value is rejected as an invalid format.

Adding a GSTIN

type=GSTIN applies the following checks, in order. The first one that fails rejects the request and nothing is written. Accepted GSTIN formats:
  • The standard 15-character GSTIN — ^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z]{1}[1-9A-Z]{1}[CDSZ][0-9A-Z]{1}$, for example 29ABCDE1234F1Z5
  • Any 15-character value beginning with 99, used for UIN-style registrations
The cross-vendor duplicate check can be relaxed by an organization configuration. When your organization is set up to allow duplicate vendors based on GSTIN, Duplicate GSTIN is not raised for a GSTIN held by another vendor — the per-vendor check (GSTIN already exists for this vendor) always applies regardless.

Adding a PAN

type=PAN applies the same vendor, access, and state checks, then: The PAN is stored encrypted at rest.
There is no way to add a PAN alongside a GSTIN. For a GST-registered vendor the PAN is already implied by the GSTIN — Pazy derives it rather than storing it separately. Use type=PAN only for vendors that are not GST registered.

What Happens After the Write

Once the identifier is committed, Pazy runs a few follow-up steps:
  • Verification. The value is checked against the GST portal (for GSTIN) or the PAN service (for PAN), and the result is returned as isVerified in the response. A value that cannot be verified is still saved — isVerified is simply false.
  • Audit trail. A CREATE entry is recorded against the vendor with source API, visible through the Vendor Audit Trail API.
  • Accounting sync. If an accounting integration is connected, the new tax identifier is pushed to it.
  • MSME check. A background MSME verification is queued — for GSTIN only when this is the vendor’s first tax identifier, and always for PAN.
Verification and the audit trail are part of the request. The accounting sync and MSME check run after the record is committed and are best-effort: if either fails, the request still returns 200 OK and the identifier remains saved.

Code Examples

Adding a PAN to a vendor with no GST registration:
cURL

Success Response

HTTP Status: 200 OK Response Fields:

Response Example — GSTIN Added

Response Example — PAN Added, Not Verified

Error Responses

Invalid GSTIN Format

HTTP Status: 400 Bad Request

Invalid PAN Format

HTTP Status: 400 Bad Request

Duplicate GSTIN

Returned when another vendor in your organization already holds this GSTIN, or when this vendor already holds it. HTTP Status: 400 Bad Request

PAN Mismatch

Returned when the new GSTIN’s embedded PAN differs from the PAN of the identifiers the vendor already holds. A single vendor cannot span two PANs — create a separate vendor for the other legal entity. HTTP Status: 400 Bad Request

PAN Not Allowed

Returned when a PAN is added to a vendor that already has a GSTIN or a PAN. HTTP Status: 400 Bad Request

Tax Identifier Belongs to Your Own Business

Returned when the submitted GSTIN or PAN resolves to one of your own organization’s PANs. HTTP Status: 400 Bad Request

Vendor Not Active

Returned when the vendor is in any state other than ACTIVE or APPROVAL_PENDING — for example a disabled vendor. HTTP Status: 400 Bad Request

Validation Error

Returned before any processing when the request does not match the schema — a missing or unsupported type, a missing or empty value, or an unknown property. HTTP Status: 400 Bad Request

Vendor Not Found

HTTP Status: 404 Not Found

Access Denied

Returned when the caller is neither an admin / bookkeeper nor the vendor’s owner. HTTP Status: 403 Forbidden

Authentication Errors

HTTP Status: 401 Unauthorized

Permission Errors

The API key must carry vendor update permission. HTTP Status: 403 Forbidden

Internal Error

Returned when the identifier could not be persisted. The write is a single transaction, so nothing is saved and the call is safe to retry. HTTP Status: 500 Internal Server Error

Best Practices

  • Send GSTIN and PAN values in upper case — a lower-case value is rejected as an invalid format
  • Use this endpoint to add an identifier and the Vendor Taxation Update API to change one; adding a value the vendor already holds is rejected rather than treated as an update
  • Check the vendor’s current GSTIN / PAN with the Vendor Details API first — it tells you whether to POST or PATCH
  • For a multi-state vendor, add one GSTIN per state through repeated calls. All of them must share the same PAN
  • Add a PAN only for vendors without GST registration, and add it before any GSTIN — once a GSTIN exists, PAN can no longer be added
  • Treat isVerified: false as “saved but unconfirmed”, not as a failure. Re-check the vendor later if verification matters to your workflow
  • GST and PAN can also be set at creation time through the Vendor Creation API — use this endpoint for vendors that are already on record