RouteToHuman

Agent → human · pre-launch

The API your agent calls when it needs a human.

Agents are good until the moment that matters. RouteToHuman turns “route this to a person” into one HTTP call — a notification or alert today, a two-way approval on the same rails next. Durable delivery over email now; Slack is the next channel.

See the first call Sign in

Pre-launch: API keys are provisioned by the operator. Write to hello@routetohuman.com for access.

Request — POST /v1/email/sends 
curl --fail-with-body --request POST \
  https://api.routetohuman.com/v1/email/sends \
  --header "Authorization: Bearer $ROUTE_TO_HUMAN_API_KEY" \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "emailAddress":"[email protected]",
    "subject":"Review requested",
    "body":"Please review the deployment."
  }'
Receipt — 202 Accepted, unedited 
{
  "id": "f8f00ad9aee84e77ad569dc88f9d38c5",
  "status": "accepted",
  "senderAddress": "[email protected]",
  "providerOperationId": "provider-operation-id",
  "createdAt": "2026-07-24T12:00:00Z",
  "updatedAt": "2026-07-24T12:00:01Z",
  "caveat": null
}

Accepted · receipt persisted

How it works

One call. A durable path to a person.

  1. 01

    Call

    Your agent — or the server it runs on — POSTs /v1/email/sends with an organization-scoped API key and a required Idempotency-Key. Keys begin rth_live_; we store only their SHA-256 hashes.

  2. 02

    Deliver

    RouteToHuman queues the message durably and sends it from robot@routetohuman.com via Azure Communication Services. Retry safely: the same idempotency key never sends twice — a replay returns the original receipt with Idempotency-Replayed: true.

  3. 03

    Prove

    Every accepted send returns 202, a Location header, and a durable receipt you can read back any time. Receipts are organization-isolated: another org’s key gets 404, not your data.

The API

Small surface, exact contract.

One public operation today: POST /v1/email/sends at api.routetohuman.com. The contract below is the real one — limits included, no asterisks.

Sender
robot@routetohuman.com — fixed, cannot be overridden
Auth
Organization-scoped API key, single email.send scope, revocable, stored as a SHA-256 hash
Idempotency
Idempotency-Key required on every send; reuse with a different payload returns 409 Conflict
Errors
RFC 9457 Problem Details (application/problem+json) with a stable code field
Limits
Subject 1–200 chars · body 1–10,000 chars · 30 sends/org/minute (429 + Retry-After: 60)
Telemetry
Recipient addresses, subjects, and bodies never enter application telemetry; receipts store hashes and provider operation IDs
Send — bash 
curl --fail-with-body --request POST \
  https://api.routetohuman.com/v1/email/sends \
  --header "Authorization: Bearer $ROUTE_TO_HUMAN_API_KEY" \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "emailAddress":"[email protected]",
    "subject":"Review requested",
    "body":"Please review the deployment."
  }'

Transactional messages only — the API is for routing moments to people, not newsletters. accepted means the provider took the operation; it is not proof of inbox delivery, and we say so in the receipt.

MCP-native

Your agent doesn’t need glue code.

The same capability is exposed as an MCP tool server over Streamable HTTP at mcp.routetohuman.com/mcp. Point an MCP-capable agent at it and “route to a human” becomes a tool the agent can call — same keys, same idempotency, same receipts as the HTTP API.

Client config — mcp.json 
{
  "mcpServers": {
    "routetohuman": {
      "type": "http",
      "url": "https://mcp.routetohuman.com/mcp"
    }
  }
}

Where this is

Shipping in the open, honestly.

Today

  • One-way sends: notifications and alerts by email, delivered via Azure Communication Services
  • Durable receipts with required idempotency — a retried call never double-sends
  • MCP tool server for MCP-capable agents

Next

  • Slack as a delivery channel
  • Two-way human-in-the-loop approvals — the human’s reply routes back to the agent on the same rails
  • Provider delivery events updating receipt status beyond accepted

No testimonials yet — nobody has used it long enough to give one. No pricing page yet — we haven’t set pricing. When those exist, they’ll be real.