Contacts execution
Read the exact action guide for prerequisites, identifier discovery, supported input, effects, captured successful and refused responses, verification and recovery. Synthetic fixture results do not authorize a live mutation or establish a provider outcome.
- List contacts: List customers and suppliers. Filter to one role or include archived contacts, search across name, legal name, email, phone, tax number and city, and sort by name, city, country or when the contact was added.
- Create a contact: Add a customer, a supplier, or a business that is both. The name is unique among live contacts in the workspace, so an import that runs twice will not duplicate it.
- Get a contact: Read one contact with its billing details and the accounts it defaults to on an invoice or bill.
- Get contact statement: Read one customer or supplier statement: issued invoices and bills, their payments, per-currency receivable and payable balances, and a paginated transaction history. Draft and void documents are excluded.
- Update a contact: Change a contact's details or roles. A contact must remain a customer, a supplier, or both.
- Archive a contact: Archive a contact so it is no longer offered on new documents. Contacts are never deleted, because invoices and bills refer to them.
- Restore a contact: Bring an archived contact back, provided no live contact has taken its name.
- List contact people: List the named people attached to a contact, with their role, email, phone, primary flag and archive status.
- Create contact person: Add a named person to a contact. The first active person becomes primary automatically; choosing another primary moves that designation.
- Update contact person: Change a person attached to a contact or make them the primary contact.
- Archive contact person: Archive a person without removing the contact record. If they were primary, another active person becomes primary.
- Restore contact person: Restore an archived person. They become primary only when the contact has no active primary person.
Evidence
Actual Books route handlers and the exported Worker were exercised against five local SQLite D1 concern databases with all committed migrations, the real posting Durable Object and local R2. Route captures use synthetic verified Auth; Worker captures use synthetic Auth transports. Nexus, Brand, Notify, Pay, Mercury and Xero responses are explicitly simulated at the provider transport boundary. Captures prove local request/response behavior and canonical SDK projection, not live bank access, payment movement, email delivery, provider eligibility, tax compliance, encrypted custody, scheduled execution, deployment or production completion. Fixture identities, credentials, addresses and records authorize no live operation.