Staff agent connections
/app/<orgSlug>/assistant/connections lists the person's approved external staff
assistant connections. Staff OAuth access is separate from customer commerce.
The connection card distinguishes Connected and Disconnected, with limits
for reading permitted Soupy records and preparing Booking requests for review.
Those limits restrict existing authority; they grant no workplace role or record.
To change a connection, select its permission limits, review the confirmation statement and save. Disconnect requires its own review and blocks new tool calls and pending approvals. Completed Bookings remain intact. Reconnecting or changing limits invalidates old pending approvals. Browser sign-out and disconnecting an external client are different actions.
A staff client can prepare supported Booking creations, moves, unpaid cancellations and bounded whole-itinerary replacements; consent-neutral contact creation/name-and-phone updates; original-seller payment requests; and eligible full remaining online refunds. Each supported write is an expiring immutable proposal, not a direct model command. Capability-mode workplace access, approved client configuration and exact source rights are required.
/app/<orgSlug>/assistant/actions/<proposalId> is the authenticated owner review
screen. It shows the source-supported customer, venue, timing, before/after terms
and consequences. Only the proposal owner with current source access can confirm.
Stale source data or a revoked connection stops approval. A payment request's
bearer link is deliberately revealed by the browser owner, not disclosed to the
agent. A requested refund is not proof that money has reached the customer.
Whole-itinerary changes require the supported same-venue/source-Order shape and unchanged party, product, currency and total. Cross-venue, price-changing or other unsupported cases return to the Booking workspace. A quote itself holds nothing.
Business participation in customer services
Settings → External services (/app/<orgSlug>/settings/external-services)
controls discoverability for customer assistants and approved partners.
Organization settings permission is required. Test services and Live
services have separate policy records.
The screen contains:
- Business enablement, directory name, description and service categories.
- Optional reviewed public address, locality, country and map coordinates.
- Published service selection, with source eligibility shown per environment.
- All supported published offers or an explicit allowlist of named listings.
- Approved-partner and bounded customer-autonomy switches.
- A client restriction list for independently approved assistant clients.
- Save unpublished settings, Save and publish listing, and Withdraw listing.
An empty named-offer list shares no offers for that service. Selecting all offers also governs future source publications. An empty client restriction list uses the default policy for independently approved clients; it does not mean an unapproved application is authorized.
Partner integration choices belong to the current business and the selected Test or Live environment. Only its active installations are listed; another business's integration details and revoked installations are unavailable. Independently approved OAuth client choices remain shared according to their existing policy.
Publication is explicit. Saving settings does not complete provider approval, make a private source listing public, change seller routing or prove a purchase. Food distribution has an additional exact item-and-modifier review; saving that review does not publish the menu or certify an external distribution provider.
Public directory and customer account
/services, /services/<businessId> and /services/<businessId>/<service> expose
opted-in businesses and their eligible published offers. Search and empty states
distinguish no matches from a directory that is not configured or unavailable.
Removed business participation makes its listing unavailable.
The separate customer account at /consumer contains purchases, connections,
payment methods and finite standing permissions (Mandates). Customer approval
screens show the original seller, exact quote, full commitment, amounts due now
and later, terms and requirements before confirmation. Aftercare previews have
separate review; the original purchase permission does not approve a later change.
A request to change food fulfilment is not confirmation that preparation stopped.
Customer credentials, ownership and spending limits never become staff authority. Provider authentication may still require the customer to return. A connected assistant should refresh the source receipt to verify success rather than treat an optional status notification as final evidence.