Skip to main content
Payment Request Details 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 Read 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. Any other role gets a 403 ACCESS_DENIED — see Error Responses.

Request

Path Parameters

Only payment requests of type VENDOR_ADVANCE are supported today. Requesting any other payment request type returns a 400 VALIDATION_ERROR — see Error Responses.

Code Examples

Success Response

HTTP Status: 200 OK Response Fields:

Tags Object

tags is keyed by tag/field slug. Predefined organization tags (cost centre, department, location, expense head) carry the selected value’s id alongside its value; custom fields carry only a value.

Response Example

Error Responses

Validation Errors

HTTP Status: 400 Bad Request Returned when paymentRequestId fails schema validation (empty, or longer than 100 characters).

Unsupported Payment Request Type

HTTP Status: 400 Bad Request The identifier resolves to a payment request that isn’t a vendor advance (e.g. a direct payment, reimbursement group, or bulk payout).

Payment Request Not Found

HTTP Status: 404 Not Found

Access Denied

HTTP Status: 403 Forbidden The API key’s user is not an admin or bookkeeper:
The request exists but has not been submitted yet, so it isn’t readable over the API:
The request is a bulk payout and bulk payout isn’t enabled for the organization:

Authentication Errors

HTTP Status: 401 Unauthorized

Permission Errors

HTTP Status: 403 Forbidden

Best Practices

  • Use tax.subTotal (not amount) when you need the pre-tax value the advance was raised for — amount is the net payable after GST, TDS and round-off
  • Treat purchaseOrderLink and payer as optional; both are null for advances raised without a PO link or before a payer is resolved
  • Poll state, approvalState and paymentState together to track a request end-to-end: state covers approval, paymentState covers settlement
  • Store the paymentRequestId returned by Vendor Advance Creation at create time rather than looking the request up by sequence number later