Documentation

Product overview

What Textree ships today in alpha: Phoenix-native auth, suppression-gated messaging, verified webhooks, and controlled MCP execution.

Product overview

Textree is an outbound messaging control plane for agentic and developer-facing products.

The public site runs in Astro. The authenticated app, JSON API, webhooks, and MCP endpoints run in Phoenix. Neon-backed Ecto data and Oban workers hold the operational state.

What exists today

The current alpha includes five concrete surfaces:

  • a public Astro site for product pages, docs, and blog content
  • an authenticated Phoenix operator console at /app
  • a developer API for queuing and reading outbound messages
  • verified webhook ingestion for messaging and funding providers
  • MCP tool listing and execution with scopes, quotas, timeouts, and audit records

Operator workflow

Textree is usable today, but some setup still lives in the authenticated app rather than a public API:

  1. Register or log in through Textree.
  2. Use a Textree access token with the required API or MCP scopes.
  3. Confirm the recipient is not under a workspace or campaign suppression.
  4. Set a spend limit in /app.
  5. Optionally create a Peer funding session in /app.
  6. Send messages through POST /api/v1/messages.
  7. Track message state through GET /api/v1/messages/:id and provider events in /app.

Current guardrails

  • Phoenix-native auth identities are normalized into local Textree users.
  • Outbound SMS does not require a global granted consent record.
  • Workspace suppressions block all outbound sends to that phone number.
  • Campaign suppressions block only that campaign’s rendered deliveries.
  • Provider STOP/opt-out webhooks create or update workspace suppressions before future sends.
  • Spend is authorized before a provider call is enqueued.
  • Provider webhooks are verified, normalized, deduplicated, and replayable.
  • MCP execution is constrained by Textree token scopes, server allowlists, quotas, and timeout policy.

Current alpha constraints

The docs in this site describe the implemented alpha, not the eventual product surface.

  • Workspace/campaign suppression management, spend limits, and funding session creation are operator workflows in /app, not public JSON endpoints.
  • Messaging is adapter-driven and stays behind a provider boundary.
  • Funding is optional and currently lives behind the Peer provider boundary.
  • MCP tools are configured server-side; there is no public tool-registry editor yet.
  • Repo-local ADRs define the current implementation baseline while canonical spec import work remains open.