Skip to main content
Vendor Advance Creation API

Authentication

All requests require an API key in the request headers. Headers:
The permission required on your API key is Payment Request with the Create action enabled.
In addition to the API key permission, the user the API key belongs to must have an admin or bookkeeper role in the organization, and vendor advances must be enabled for the organization. Either check failing returns 403 ACCESS_DENIED — see Error Responses.
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

Unknown body properties are rejected rather than ignored — sending any field not listed above returns a 400 VALIDATION_ERROR.

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 (PERCENTAGE or ABSOLUTE) 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.
Fetch the ids and their rates from the TDS Taxes and GST Taxes APIs, compute the expected amounts from the returned 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:
The round-off follows the organization’s configured rounding behaviour. The resulting net payable is what Payment Request Details returns as amount, with your original value available there as tax.subTotal.

Purchase Order Linking

When purchaseOrderLinkId 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 with MISSING_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 PENDING state and the approval workflow starts, notifying approvers.
  • Policy has no approval stages → the request is created already APPROVED.

Code Examples

Minimal Request

Only amount 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:
An id that doesn’t resolve to a tax of the right type for this organization:
An amount that disagrees with the rate configured against the id:

Currency and Entity Errors

HTTP Status: 400 Bad Request

Vendor Not Found

HTTP Status: 404 Not Found
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:
Vendor advances aren’t enabled for the organization:

Duplicate Idempotency Key

If the same x-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
An 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-key per advance so a timeout retry can’t create a duplicate payment request
  • Send amount as the pre-tax value; adding GST or subtracting TDS yourself will fail the tax amount validation
  • Treat the Invalid gstAmount/Invalid tdsAmount messages 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_FIELD failures
  • Store the returned paymentRequestId and track approval progress via Payment Request Details