Messaging rails for AI agents

Put your agent on the wire.

One API — MCP-native and plain REST — to send and receive across WhatsApp, Telegram, SMS/RCS, email, Slack, Discord and Teams. Inbound routes to the model you already run, signed and retried; you answer with one send_message.

No inference inside — bring your own model.

agentpush — live wire
→ sarahYour order #4218 is on its way.delivered
→ sarahread
← karimcan you move my booking to 6pm?inbound
→ your-agentPOST /inboundsha256 ✓
send_message({ to: karim, text: "Done — moved to 18:00." })
→ karimDone — moved to 18:00.delivered

The rails

Seven rails. One verb.

  • whatsapp

    Business Cloud API · templates + session windows

  • telegram

    Bot API · webhook-native

  • sms / rcs

    carrier rails · Twilio

  • email

    Gmail & Resend

  • slack

    Events API · signing secret

  • discord

    bot · Ed25519-verified

  • teams

    Bot Framework

  • send_message()

    the same call on every rail

How it works

Connect. Route. Reply.

  1. 01

    Connect a rail

    Attach a provider account to your workspace — token in, webhook registered, rail live. Or click through the dashboard.

    POST /provider-accounts
    {
      "provider": "whatsapp",
      "credentials": { "token": "…", "phoneNumberId": "…" }
    }
  2. 02

    Inbound finds your agent

    Every incoming message is workspace-resolved, matched against your routes, and POSTed to your endpoint — HMAC-signed, journaled before dispatch, retried until you ack.

    POST https://your-agent.dev/inbound
    X-Agentpush-Signature: sha256=…
    
    { "channel": "whatsapp", "from": "+33612…",
      "text": "can you move my booking to 6pm?" }
  3. 03

    Reply with one verb

    Your model decides; agentpush delivers. One send_message answers on the rail the message came from — text, template or media.

    send_message({
      to: { channel: "whatsapp", address: "+33612…" },
      content: { text: "Done — moved to 18:00." }
    })

Two surfaces

MCP for your agent. REST for everything else.

mcp — Claude Code, Claude, any MCP client
// your agent calls the tool directly
send_message({
  "to": { "channel": "whatsapp", "address": "+33612345678" },
  "content": {
    "text": "Your table is confirmed for 20:00.",
    "media": [{ "type": "document", "url": "https://…" }]
  }
})
rest — curl, cron, your backend
# same verb, plain HTTP
curl https://api.agentpu.sh/tools/send_message \
  -H "Authorization: Bearer $AGENTPUSH_KEY" \
  -d '{
    "to": { "channel": "telegram", "address": "karim" },
    "content": { "text": "Done — moved to 18:00." }
  }'

send_message · send_broadcast · find_contact · upsert_contact · list_templates · check_delivery · upload_media · inbound_route_create · …

Built in

The parts you'd otherwise build.

  • MCP-native and REST

    The same tools speak MCP to Claude and friends, and plain HTTP to everything else. One auth header, no SDK required.

  • Bring your own inference

    agentpush runs zero models. Inbound routes to the endpoint you point it at — your LLM, your prompts, your stack.

  • Signed webhooks

    Every delivery to your agent carries X-Agentpush-Signature — HMAC-SHA256 over the raw body. Verify one header, trust the payload.

  • Durable delivery

    Inbound notifies are journaled before the first dispatch and retried until acknowledged. A crash mid-flight loses nothing.

  • Media on every rail

    Images, video, audio, documents — one normalized shape across channels, by public URL or provider media id.

  • Multi-tenant by design

    Workspaces isolate keys, contacts, routes and spend. Run every client and every product on one deployment.

Your agent already knows what to say.

Give it the rails. Connect a channel, point a route at your endpoint, and answer your first inbound this afternoon.