Vendor Advance Creation API
Payment APIs
Vendor Advance Creation API
Raise a vendor advance payment request, optionally linked to a purchase order
Vendor Advance Creation API
Authentication
All requests require an API key in the request headers. Headers:x-idempotency-key is optional but strongly recommended on this endpoint. When supplied, a repeat request with the same key within 5 minutes is rejected with 409 Conflict instead of creating a second advance. Generate a new unique value (e.g. a UUID) per logical advance, and reuse it only when retrying that exact attempt.Request
Content-Type:application/json
Body Parameters
Tax Handling
GST and TDS are both optional, and each id must travel together with its amount:- Both omitted — the tax is treated as not applicable and contributes
0. - Both supplied — the amount is recomputed server-side from the tax’s configured rate (
PERCENTAGEorABSOLUTE) and compared against the value you sent. A mismatch rejects the whole request, so you always know the exact tax before the advance is created. - One supplied without the other — rejected with
400 VALIDATION_ERROR.
rate and rateType, and send them alongside the ids.
Amount Calculation
amount is the pre-tax value. The net payable stored on the request is derived as:
amount, with your original value available there as tax.subTotal.
Purchase Order Linking
WhenpurchaseOrderLinkId is supplied, the purchase order must satisfy all of the following, or the request is rejected:
- It exists in the organization
- It belongs to the same vendor as
vendorId - Its state is
APPROVED - Its matching state is
UNMATCHED - It is not already linked to another advance (including one pending resubmission)
- The advance’s net payable does not exceed the purchase order amount
Tags Object
tags is keyed by tag or custom-field slug, with each entry wrapping the value in a value property. Dropdown tags (including the predefined cost centre, department, location and expense head tags) take the value id; text, numeric and date fields take the literal value.
To discover the available tag slugs, their types, and (for
DROPDOWN tags) the valid value ids, see the tag APIs: the Tag List API, and Tag Detail API.Submission and Approval Policies
The organization’s submission policy is enforced strictly: if it marks any field mandatory for a procurement of this amount, that field must be present or the request fails withMISSING_REQUIRED_FIELD listing every missing slug. Note that sending narration satisfies a required description field, and sending purchaseOrderLinkId satisfies a required identifier field.
The organization’s approval policy is then matched against the payload (amount, vendor, tags, PO), falling back to the organization’s default policy when no rule matches. The name of the policy that was applied comes back as policyUsed:
- Policy has approval stages → the request is created in
PENDINGstate and the approval workflow starts, notifying approvers. - Policy has no approval stages → the request is created already
APPROVED.
Code Examples
Minimal Request
Onlyamount and vendorId are required — taxes, currency, PO link and tags are all optional (subject to the organization’s submission policy):
Success Response
HTTP Status:200 OK
Response Fields:
Response Example
Creation is atomic — the advance, its tag mappings, the payment request, its payers and the approval workflow all commit together. If any step fails, nothing is created.
Error Responses
Validation Errors
HTTP Status:400 Bad Request
Schema-level failures:
Tax Errors
HTTP Status:400 Bad Request
An id sent without its amount, or vice versa:
Currency and Entity Errors
HTTP Status:400 Bad Request
Vendor Not Found
HTTP Status:404 Not Found
Purchase Order Link Errors
HTTP Status:400 Bad Request
All PO link failures return VALIDATION_ERROR; the message identifies which check failed:
Missing Policy-Mandated Fields
HTTP Status:400 Bad Request
The organization’s submission policy requires fields that weren’t supplied. Every missing slug is listed:
Policy Resolution Errors
HTTP Status:400 Bad Request
The applicable approval policy could not produce a usable payer — usually a misconfigured procurement policy that needs fixing in Pazy:
Access Denied
HTTP Status:403 Forbidden
The API key’s user is not an admin or bookkeeper:
Duplicate Idempotency Key
If the samex-idempotency-key is reused within 5 minutes of the original request, it is rejected before any processing happens. Note this error uses a different response shape than the rest of this API:
HTTP Status: 409 Conflict
x-idempotency-key that is present but empty, over 256 bytes, or contains control characters:
HTTP Status: 400 Bad Request
Authentication Errors
HTTP Status:401 Unauthorized
Permission Errors
HTTP Status:403 Forbidden
Best Practices
- Read the tax ids and rates from TDS Taxes and GST Taxes at the start of each run rather than hardcoding ids — rates change, and a stale id fails the amount check
- Send a unique
x-idempotency-keyper advance so a timeout retry can’t create a duplicate payment request - Send
amountas the pre-tax value; adding GST or subtracting TDS yourself will fail the tax amount validation - Treat the
Invalid gstAmount/Invalid tdsAmountmessages as authoritative — they carry the server-computed figure, so you can correct and resubmit directly - Read the organization’s submission policy requirements once and include those tags on every request, instead of discovering them through
MISSING_REQUIRED_FIELDfailures - Store the returned
paymentRequestIdand track approval progress via Payment Request Details