Endpoint index

The guides in Build cover the main integration paths end to end. This page indexes what they leave out: endpoint families that exist in the sidebar reference with full request and response schemas, but that no guide walks you through. If you went looking for something and concluded it did not exist, check here before you build around it. Some of these families are also tracked on Can I…? with caveats — check your row there before committing to one.

​

Two different /search endpoints

Twelve resources expose POST /<resource>/search, and the suffix hides two unrelated contracts. External-key lookup — takes sourceSystem and sourceSystemId as query parameters and answers “which Upwell record corresponds to mine?”: bill-payments · purchase-orders · shipment_line_items · vendor-invoices · vendors Filtered list — takes limit and offset as query parameters plus a filter body, and answers “which records match these criteria?”: bills · carriers · customer_payment_line_items · customer_payments · customers · invoices · shipments The two forms fail differently when misused. The external-key form’s two parameters are required — omitting them fails the request. The filtered form’s parameters all have defaults (limit 10, offset 0, empty filter), so a request that omits or mis-names its filter can succeed anyway and return the first page of unfiltered rows instead of an error. Pagination on the filtered-list form follows the same limit/offset rules as any list GET, including the default limit of 10.

​

Invoice queues

Two read-only endpoints return customer-invoice work queues, so you can drive your own review UI from them. Both accept limit and offset, and both return an invoicesAggregate count alongside the rows. The two queues are not nested — an invoice can appear in one, both, or neither, so read each one on its own rather than treating the first as a subset of the second.

​

Approving

These approve on the Upwell side. If your own system owns the approve/reject decision, the flow you want is approval requests instead. For what approval means downstream, and what blocks it, see Approvals.

​

Bill payments

The money-out side of accounts payable. Bills themselves are covered in the AP overview; their payments are not.

• GET /bill-payments — list, limit/offset
• POST /bill-payments — create
• POST /bill-payments/search — external-key lookup
• GET, PUT, DELETE /bill-payments/{id}

Bill line items are managed separately: POST /bill_line_items, then PATCH or DELETE /bill_line_items/{id}.

​

Shipment structure

Shipments are covered in Syncing foundation entities, but two of their child resources are not. Stops — GET/POST /stops, and GET/PUT/DELETE /stops/{id}. Stops carry the pickup and delivery detail for a shipment. Shipment line items — the freight detail for one commodity on a shipment: description, packaging and handling units, weight, dimensions, NMFC number and class, and the hazmat flag. Create with POST /shipment_line_items, then GET, PATCH, or DELETE /shipment_line_items/{id}. shipmentId is required on create. Note that these update with PATCH, not PUT.

​

Payment line items

Line items on payments are addressable individually, which is how you correct a single allocation without rewriting the payment:

• GET, PUT, DELETE /carrier_payment_line_items/{id} — creating them (POST /carrier_payment_line_items, plus the bulk variant) is covered in Recording carrier payments; the by-id operations are only in the reference.
• GET, PUT, DELETE /customer_payment_line_items/{id}, and POST /customer_payment_line_items/search for the filtered-list form.

Customer payments themselves — GET/PUT/DELETE /customer_payments/{id} and POST /customer_payments/search — are walked through in Managing customer payments.

​

Documents

The two-step upload flow is covered in Working with documents, listing a carrier invoice’s documents in Knowing when a carrier invoice is processed, and polling parsed vendor invoices out of an uploaded document in Purchase orders & vendor invoices. What no guide covers is attaching and detaching: Document reference specifications — GET/POST /document_reference_specifications and GET/PUT/DELETE /document_reference_specifications/{id} define per-customer name and format patterns used to validate the reference numbers on documents.

​

Covered in guides, easy to miss

Two families often assumed missing are documented — just not where people look first:

• Unlinking an invoice from a shipment — DELETE /invoice_shipments/{invoiceId}/{shipmentId} removes the association without deleting either record. Worked example in Customer invoices.
• Bulk creates — the family is wider than the two endpoints most people find: bulk-bills, bulk-carriers, bulk-customers, bulk-carrier-invoices, bulk-customer-payments, bulk-customer-payment-line-items, and bulk-carrier-payment-line-items. Replay behavior differs per endpoint — bulk-bills upserts on the external key while bulk-carriers fails the entire batch on a duplicate — so read Bulk create before retrying any of them.