autobot.team turns the Google Voice number already sitting in your Google account into a plain JSON API. Send messages, list conversations, and read replies — without a carrier contract or a per-message vendor in the middle.
Your number · Your Google account · JSON in, JSON out
curl -X POST https://autobot.team/api/sms/send \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"to":"+15551234567","body":"Deploy is green."}'
{
"status": "sent",
"conversation_id": "c8f1a0e2-4b77-4c31-9a5e-1d2f6b0c9a34",
"to": "+15551234567",
"gmail_thread_id": "18f2c9d4a7b13e05",
"message_at": "2026-08-20T15:04:11Z"
}
The whole surface
Five endpoints. No SDK to install, no webhook to host, no message queue to operate.
Why this exists
Sending one programmatic text usually means opening an account with a messaging vendor, provisioning a second number nobody recognizes, and paying per message forever. Meanwhile the number you actually use is sitting in Google Voice, reachable only by hand.
Messages come from the number people already have for you, so replies land in the same thread instead of a stranger’s shortcode.
The grant is yours and revocable from your own Google security page. There is no vendor holding a copy of your message history.
An HTTP client and a bearer token are the entire integration. Anything that can POST can text — a cron job, a CI step, a shell one-liner.
Quickstart
One consent screen grants read-and-send on the Gmail mailbox that backs your Google Voice number. After that every message is an ordinary authenticated request.
Grant read-and-send on the mailbox behind your Voice number. Stored once, refreshed automatically, revocable by you at any time.
Exchange your account login for a bearer token. Send it on every call as an ordinary Authorization header.
One call with a recipient and a body. The response tells you the conversation it landed in and when it was sent.
# 1. exchange your login for a bearer token TOKEN=$(curl -sD- -o/dev/null -X POST https://auth.trycopilot.ai/login/ \ -H "Content-Type: application/json" \ -d '{"email":"[email protected]","password":"..."}' \ | grep -o 'auth_token=[^;]*' | cut -d= -f2) # 2. send curl -X POST https://autobot.team/api/sms/send \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"to":"+15551234567","body":"Build 349 is live."}' # -> {"status":"sent","conversation_id":"c8f1a0e2-...","message_at":"..."}
API reference
Every route takes and returns JSON. Identifiers are stable, so a conversation you saw yesterday is the same conversation today.
{
"conversations": [
{
"conversation_id": "c8f1a0e2-4b77-4c31-9a5e-1d2f6b0c9a34",
"to": "+15551234567",
"subject": "SMS with +1 555 123 4567",
"gmail_thread_id": "18f2c9d4a7b13e05",
"last_message_at": "2026-08-20T15:04:11Z",
"last_seen_at": "2026-08-20T15:04:12Z"
}
]
}
{
"conversation_id": "c8f1a0e2-4b77-...",
"to": "+15551234567",
"messages": [
{
"message_id": "9d31f0b8-...",
"direction": "outbound",
"body": "Build 349 is live.",
"message_at": "2026-08-20T15:04:11Z"
},
{
"message_id": "4a77c2e1-...",
"direction": "inbound",
"body": "nice, thanks",
"message_at": "2026-08-20T15:06:02Z"
}
]
}
Receiving
Because every conversation is backed by a real mail thread, an inbound reply is durable the moment it arrives. You poll when it suits you instead of standing up a public endpoint and hoping the delivery retries reach it.
A job behind a firewall, a laptop, or a CI runner can read replies. None of them need to be reachable from the internet.
Messages are not events you can miss while your consumer is down. They are still in the thread when you come back.
Each message carries inbound or outbound and a timestamp, so reconstructing a conversation needs no guessing.
For agents
The same API ships with instructions written for an autonomous caller rather than
a human reader. Point an agent at /SKILL.md and it has everything it
needs; the one-command path is a single pipe with no install step.
# no clone, no dependency, no SDK curl -s https://autobot.team/SKILL.py \ | python3 - --body "Deploy finished." # or to a specific recipient python3 SKILL.py --body "text" --to +15551234567 # see the request without sending it python3 SKILL.py --body "text" --dry-run
FAQ
Neither. The API drives the Google Voice number already attached to your Google account, so messages come from the number people recognize, and there is no second provisioning step.
Read-and-send on the Gmail mailbox that backs your Voice number, which is what sending and reading a text actually requires. The grant lives in your Google account and you can revoke it there at any time, without asking anyone.
Read them. Inbound replies land in the conversation and are returned by the conversation endpoints, tagged inbound. There is no webhook to host and no event you can miss while your process is restarting.
Practically, yes — this rides a personal Google Voice number, which is provisioned for a person rather than a broadcast. It suits alerts, confirmations, and agent notifications, not bulk campaigns.
To anyone you could text by hand from that number. Delivery, carrier behavior, and the recipient's ability to reply are exactly what they would be in the normal app.
Calls that need it fail with a clear error and a link back to the consent screen, rather than silently accepting a message that will never be delivered. Reconnecting restores the same conversations.
Get started
Connect the Google account behind your Voice number and send your first message in the next few minutes.
Your number · Your Google account · Revocable any time