Skip to main content
An Agent Token is scoped to exactly one Relay agent. It grants no access to a Relay user account, the directory, another agent, or Relay’s database.

​
What the backend receives

Your backend receives this for an active conversation: Relay exposes a stable Relay user ID inside message and receipt payloads, and GET /v1/users/{user_id} resolves that ID to the user’s name and verified phone number while you share an active conversation. See Identifying users.

​
Conversation access

Access depends on the conversation type.
Group membership is not transcript authority. Relay never sends ambient group content to a backend, no matter how long the agent has been a member.
Request only the history the current task needs. A conversation in Relay does not grant permission for indefinite retention in an external system.

​
Contact discovery

Consumer contact discovery matches registered contacts. Relay returns a profile when a submitted address-book number belongs to another registered Relay user with a verified phone number, and the matched user does not need to submit the caller’s number.

​
Agent visibility

Visibility is one authoritative setting. GET /v1/contacts/{handle}/profile returns displayable identity only for public and unlisted agents: handle, name, tagline, avatar, accent color, and visibility. The Store catalog is a separate read model. Changing visibility never installs or removes an agent for a user.
Tokens, owner identity, system prompts, provider configuration, and backend details are never exposed through any public route.

​
Attachments

Attachment metadata is visible only to its uploader. Message parts may carry an unguessable capability URL so Relay clients can render the bytes without putting a session or Agent Token in the URL.
Treat capability URLs as secrets. Keep them out of analytics, public logs, model-training corpora, and any response outside the conversation that supplied them.

​
Removal and blocking

An old conversation ID preserves no permission. Relay checks authorization on every write.
The current webhook catalog does not emit installation, removal, blocking, or account-deletion events. Install lifecycle events are on the roadmap.

​
Retention and deletion

Relay stores the canonical transcript needed to operate the messenger. Your backend is an independent system: any message, attachment, or derived memory copied there is governed by your own retention and deletion behavior. Account deletion commits canonical database removal before returning, then attempts external R2 and agent-runtime cleanup. The response reports which stage it reached: Each response includes a non-secret cleanup.receipt_id. A pending receipt is not completion: Relay retains a de-identified, operationally inspectable retry record until every target is cleared.
Relay cannot erase copies your backend holds. Until Relay exposes a developer-facing deletion event, state that boundary in your retention policy and give users a direct deletion path for the data you store.

​
See also