Skip to main content

​
Overview

A shipper profile is Upwell’s customer record: the party you bill and collect from. Every receivables feature keys off it — invoice delivery reads the customer’s billing address and email, aging and reminders read its payment terms, and payments apply against its invoices.
In the data model and the API this object is simply the customer (cus_…). “Shipper” is the freight-side word for the same party — see the data model for how customers relate to shipments and invoices.

​
What it holds

​
Identity and contact

  • Name, email address for invoice delivery, and phone
  • The billing address — a separate, typed address record (CUSTOMER_BILLING), at most one per customer, which the invoice bill-to block and delivery routing read
  • Your external key (sourceSystem + sourceSystemId) tying the record back to your TMS

​
Billing configuration

  • Payment terms (paymentDiscountTerms, e.g. "Net 30") — drives aging and reminder timing
  • Bill-to hierarchy (billToCustomerId) — point child accounts at the corporate parent they bill through, for enterprises with many shipping locations and one payer
  • Custom data — the customer record carries a metadata field for integration-specific attributes

​
History

  • Shipments, invoices, and payments all reference the customer, giving a per-account view of activity and payment behavior in the dashboard

​
For developers

Sync customers

POST /api/rest/customers, updates by id or by external key, and the bill-to hierarchy fields.

Billing addresses

The address playbook: the one-CUSTOMER_BILLING-per-customer rule and the match-by-type update pattern.
Contacts, locations, and customer documents are not separate API resources — there are no /customer-contacts, /customer-locations, or /customer-documents endpoints. Locations are modeled as typed addresses, and shipper-facing documents attach to shipments and invoices (see How documents flow through Upwell).