Customer app

Customers have no password — the portal signs them in by emailed link, and the app uses the same one. The link lands in a browser, which hands the session to the app through /portal/auth/handoff, so generate a PKCE verifier first and pass its challenge here: it is what the handover code will be bound to.

Always 202. An address with no account, a blocked one and a real one are indistinguishable in the answer — anything else would turn this into a directory of a workspace's customers.

Where the magic link ends up. With the portal cookie the browser just received, it redirects to the app's URL scheme carrying a one-time code. Not called by the app itself — the app waits for the deep link.

Trades the handover code for a session bound to this phone. Single use, two minutes.

Identity and organization (MC-05). workspace.locale is the language to render in: the product runs one language per workspace, so there is deliberately no per-customer language to write.

scope=mine is theirs; scope=organization is their company's, and only where that company has ticket sharing turned on. The fifty most recently updated, unpaginated — next_cursor is always null.

Files the request on the portal channel and runs the same rules, SLA policies and notifications as the web portal — a request typed on a phone is not a second kind of request.

Public replies only — internal notes are excluded by the query itself. A request that is not the customer's answers 404, never 403: otherwise the numbers become a way to count a workspace's tickets.

Only the requester may write; a colleague who can read the company's requests cannot answer in their thread. A reply reopens what was waiting, on hold or resolved.

Upsert on the token, like the agents' registrations.

Somebody answered, or a request was resolved (MC-04). Nothing about a colleague's request: belonging to an organization that shares its tickets lets someone read them, which is not being notified about them.