Customer Payable Payments

Reference for the customer_payable_payments resource. Requests follow the conventions in Requests and Responses; fields you receive and may write are filtered by your user's permissions, so responses can contain a subset of the fields below.

Operations

Operation	Request
List	`GET /{profile}/user/v4/customer_payable_payments`
Fetch	`GET /{profile}/user/v4/customer_payable_payments/{id}`
Create	`POST /{profile}/user/v4/customer_payable_payments`
Update	`PATCH /{profile}/user/v4/customer_payable_payments/{id}`
Delete	`DELETE /{profile}/user/v4/customer_payable_payments/{id}`

Required on create: link customer_payable under data.relationships — a create that omits it is rejected with 422 naming the relationship.

How it works

customer_payable_payments are the payments recorded against a payable (a customer_payables record — a payroll/commission amount owed to a payee tied to a customer). Gated by Customer Payables at the customer's location.

This is the modern/ledger payment surface. A payment always belongs to a payable; the payable's paid balance is the sum of its payments. Tenants still on the legacy payables model track payment with scalar fields on the payable instead, and this endpoint has no rows for them.

POST to record a payment, PATCH to edit, DELETE to remove.

curl -X POST "https://portal.securitytrax.com/acme/user/v4/customer_payable_payments" \
  -H "Authorization: Bearer stx_acme_..." \
  -H "Content-Type: application/json" \
  -d '{"data":{"attributes":{"amount":"250.00","payment_date":"2026-07-15","reference":"CHK-1042"},"relationships":{"customer_payable":{"data":{"type":"customer_payables","id":42}}}}}'

Field	Required	Notes
`customer_payable` (relationship)	Yes	The payable this payment is applied to (`customer_payables`).
`amount`	Yes	Numeric.
`payment_date`	Yes	The date the payment was made.
`reference`	No	Check number / external reference, ≤ 255 chars.
`notes`	No	Free text.

Reading a payable's payments

GET /customer_payable_payments?payroll_to_customer_id={payableId} lists a payable's payments (filters: payroll_to_customer_id, payment_date/created_at ranges; sort: id, payroll_to_customer_id, payment_date, amount, created_at; ?count_only=true for the total).

Fields

Fields are grouped by the permission that gates them. A group you may not view is absent from responses; a group you may not write is rejected with 422 when sent in a write.

Payable Payment

View: customers — Customer Payables Info at the record's location; leads — Customer Lead Payables Info. Create: customers — Customer Payables Info at the record's location; leads — all of: Lead; Customer Lead Payables Info. Update: customers — Customer Payables Info at the record's location; leads — all of: the standard canModifyLead rules; Customer Lead Payables Info.

Field	Type	Writable	Validation
`payroll_to_customer_id`	integer (nullable)	Create, update	min 0
`payment_date`	string (nullable)	Create, update	Required on create
`amount`	string (nullable)	Create, update	Required on create
`notes`	string (nullable)	Create, update	—
`reference`	string (nullable)	Create, update	max length 255
`created_at`	string (nullable)	Read-only	—
`created_by`	integer (nullable)	Read-only	—
`updated_at`	string (nullable)	Read-only	—
`updated_by`	integer (nullable)	Read-only	—

Pagination

The list endpoint uses client-controlled offset pagination: ?page= (1-based) and ?per_page= (default 25, max 100). The response mirrors meta.pagination (page, per_page, total, last_page) and sends an RFC5988 Link header; follow rel="next" to walk pages. See Pagination.

Filters

The list endpoint accepts these query-param filters: payroll_to_customer_id, payment_date_from, payment_date_to, created_at_from, created_at_to. An unsupported filter parameter returns 422. See Filtering collections for matching semantics.

Sorting

GET .../customer_payable_payments?sort= orders the list by: id, payroll_to_customer_id, payment_date, amount, created_at. Prefix a field with - for descending; comma-separate for tie-breakers. An unsupported field returns 422. See Sorting collections.

Requests and Responses — envelope, errors, pagination, and rate limits.
Authentication — tokens and the Authorization header.