> ## Documentation Index > Fetch the complete documentation index at: https://docs.upwell.com/llms.txt > Use this file to discover all available pages before exploring further. # Endpoint index > The parts of the API reference no guide walks through, grouped by what they do 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…?](/developer-guide/can-i) with caveats — check your row there before committing to one. ## Two different `/search` endpoints Twelve resources expose `POST //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. | Endpoint | Returns | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /invoices/queues/ready-for-approval` | Customer invoices in `CREATED` status with `approvedToSend` false and no open or in-progress exceptions. | | `GET /invoices/queues/ready-to-send` | The **Ready To Send** queue: `CREATED` invoices that are not on hold, have a customer, have no open or in-progress exceptions, are not scheduled, are not manual portal work, and are not owned by a customer's auto-send email rule. `approvedToSend` may be either value. Deliberately a **superset** of the in-app Pre-Invoice Audit lane — the app also hides auto-portal invoices its automation will drain; this endpoint keeps them so you never silently lose an actionable invoice. | 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 | Endpoint | Notes | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | `POST /carrier_invoices/{carrierInvoiceId}/approve` | Approves one carrier invoice. Accepts an `overrideExceptions` query parameter to approve despite open exceptions. | | `POST /invoices/{id}/approve` | Approves one customer invoice. | These approve **on the Upwell side**. If your own system owns the approve/reject decision, the flow you want is [approval requests](/api-guides/carrier-invoice-approval) instead. For what approval means downstream, and what blocks it, see [Approvals](/concepts/approvals). ## Bill payments The money-out side of accounts payable. Bills themselves are covered in the [AP overview](/api-reference/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](/api-guides/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](/api-guides/carrier-invoice-submission#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](/api-guides/customer-payments). ## Documents The two-step upload flow is covered in [Working with documents](/conventions/documents), listing a carrier invoice's documents in [Knowing when a carrier invoice is processed](/api-guides/carrier-invoice-status), and polling parsed vendor invoices out of an uploaded document in [Purchase orders & vendor invoices](/api-guides/purchase-orders-and-vendor-invoices). What no guide covers is attaching and detaching: | Endpoint | Purpose | | ------------------------------------------------------------ | ------------------------------------------ | | `POST /carrier_invoices/{carrierInvoiceId}/documents` | Attach a document to a carrier invoice. | | `DELETE /carrier_invoices/{carrierInvoiceId}/documents/{id}` | Detach a document from a carrier invoice. | | `DELETE /invoices/{invoiceId}/documents/{id}` | Detach a document from a customer invoice. | **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](/api-guides/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](/api-guides/syncing-foundation-entities#bulk-create) before retrying any of them. Every endpoint on this page is in the sidebar reference with its full request and response schema. If something you need is missing from both, ask [support@upwell.com](mailto:support@upwell.com) rather than assuming it is unsupported — the reference is generated from the API, so absence there means the endpoint is genuinely not exposed.