Grok Bot API: Every Way to Drive a Grok Bot From Code, and How to Feed Your Own Agent Twitter (X) Data

No public API exists for the operations most people mean by "Grok Bot API": listing your Bots, creating one, sending it a message and reading its reply. On the Cursor forum feature request "Grok Bot: official API to create bots and send/receive chat (for companion UIs)", a Cursor staff member replied that there is "currently no official public API or SDK for Grok Bot for this use case (list/create bots, send message, read transcript)", that UI automation is "basically the only option right now", and that the request has been passed to the team with no timeline. xAI's Grok Bot docs at docs.x.ai/grok-bot describe talking to a Bot by messaging it in the desktop or mobile app; none of the Grok Bot pages documents a chat API.

Grok Bot runs on Cursor's infrastructure: the docs say Bots work on a persistent cloud computer in Cursor's cloud and that Grok Bot uses Cursor authentication. That is why the official programmatic surfaces live in Cursor's docs rather than in the xAI API reference. The table below lists every path we could verify, with its status.

What this means in practice. If you need to wake a Bot when something happens elsewhere, the webhook trigger is the supported tool. If you need a Bot to reach your systems, write or reuse an MCP server. If you need to hold a conversation with a Bot from another program, you are on community or undocumented ground today. And if you only want Grok plus X data inside your own product, you do not need Grok Bot at all.

A routine tells one Bot when to run a workflow. Cursor's help center (cursor.com/help/grok-bot/routines) lists the starts it supports: a schedule, a Slack message, a GitHub, Linear, Sentry or PagerDuty event, an email, or a webhook call. You create the routine by asking the Bot in chat, then ask it to add a webhook trigger. On desktop the routine's Webhook section shows three fields: POST to (the URL), key (the secret) and header (the full Authorization: Bearer <key> line).

What a call does. Send an HTTP POST to that URL with the header; you can include a JSON body, which the Bot receives together with the routine instruction. A 200 means Grok Bot accepted the call and started a run. It does not mean the Bot has finished; the result shows up in the Bot's chat. Any other response means no run started, usually because the routine is paused or the key was rotated.

Limits that matter for automation. Your routines can run up to 300 times an hour in total and each routine up to 200 times an hour; past either limit a run fails with "Automation run rate limit exceeded". A Bot can own up to 50 routines, schedules must be at least five minutes apart, and the app keeps the 20 most recent run records per routine (docs.x.ai/grok-bot/skills-routines-and-automations). Each run spends weekly Grok Bot usage, so a webhook on a noisy event source can burn a week of usage in a day.

One-way, by design. The webhook is a doorbell, not a conversation: you cannot read the Bot's answer back through it. Forum users building Slack and agent-to-agent bridges in August 2026 reported that the body did not always arrive and settled on writing the payload somewhere the Bot can read (a file, a ticket) before ringing; the current help article says the body is delivered. Either way, have the Bot report its result through a connector you can read (Slack, email, a GitHub comment) if your code needs the outcome.

Model Context Protocol is the supported way to let a Bot call your systems. Grok Bot's Team Bot docs (docs.x.ai/grok-bot/team-bots) list two kinds of custom MCP server a Bot can use: Remote HTTPS, which authenticates with the Bot's own credential or each person's OAuth sign-in, and Command, which runs on the cloud computer each conversation uses. Grok's consumer connectors page (docs.x.ai/grok/connectors) adds that a custom MCP connector must be reachable over the public internet, with tunneling as the fix for a server on your laptop.

Network policy applies. On Enterprise teams with a network allowlist, an admin can switch on Apply to MCP servers; a remote server not on the list is refused with an error naming the host (docs.x.ai/grok-bot/security). It is off by default for every team.

For X data specifically. Bots can already search and read public X without connecting an X account, read-only, and need the X plugin plus a sign-in for DMs, bookmarks, the home timeline and likes (docs.x.ai/grok-bot/computer-and-apps). Our Grok Bot overview walks through what those reads cost on X's rate card. If you prefer to bring your own X data source, an MCP server is the slot for it. Our open-source @twitterapi_io/mcp-server package (version 0.2.0 on npm, 12 read-only tools such as search_tweets, get_user_last_tweets and get_user_mentions) is a stdio server, which matches Grok Bot's Command type. We have not tested it inside Grok Bot, so treat that pairing as a reasonable fit rather than a documented recipe.

MCP in the other direction. People asking for a "Grok Bot MCP" often want the reverse: an MCP server that exposes Grok Bot to Claude Code, Codex or Cursor. No official one exists. The community grok-bot-cli package ships one (next section). And if what you need is Grok calling MCP tools from your own code, the xAI API supports remote MCP tools in the Responses API with server_url and server_label, Streaming HTTP and SSE transports only (docs.x.ai/developers/tools/remote-mcp).

The closest thing to an official "Grok Bot API" in name is the Grok Bot group in Cursor's Admin API (cursor.com/docs/account/teams/admin-api). It lets a team admin enable Grok Bot and manage capabilities, enforced Auto-review, group access, network policy, team rules and setup scripts. Authentication is a team API key over Basic auth; reads need read:* or admin:*, writes need admin:*, and the rate limit is 20 requests per minute per team per endpoint, with 429 and Retry-After: 60 past it.

Member computers (recreate, terminate, delete, or delete all Grok Bot data) are handled by the separate Organization API with an admin:* key, one operation per team at a time (docs.x.ai/grok-bot/computers). None of these endpoints creates a Bot, sends it a message or reads a conversation, so they solve fleet management, not automation.

The top result for "grok bot cli" is github.com/ScriptedAlchemy/grok-bot-cli, a community project (MIT license, published on npm as grok-bot-cli, version 0.12.4 when we checked; about 130 stars and 27 forks). It is not published by xAI or Cursor. Its README describes a gbot command that manages Grok Bot agents, groups and messages from the terminal: gbot bots list, gbot bots create --name Researcher, gbot send Researcher "...", gbot thread Researcher --after <id> --json, plus group and skill-library commands.

How it authenticates. It needs Node.js 22.19.0 or newer and the Grok Bot desktop app; after you sign in to the app once, gbot reuses the app's encrypted session and routing credentials (or GROK_BOT_GATEWAY_URL plus GROK_BOT_GATEWAY_TOKEN, or CURSOR_ACCESS_TOKEN). By default it only sends credentials to *.cursor.sh, *.cursor.com and *.cursorvm.com hosts. The package also installs a grok-bot MCP server (gbot_send, gbot_thread) for Codex, Claude Code and Cursor, and bridges for Codex threads and opted-in Claude Code sessions.

The gateway underneath. A Cursor forum thread from August 2026 documents the mechanism: the Bot's computer runs a private HTTP gateway, normally on port 1340, with a bearer token stored on that computer, accepting calls such as POST /api/listAgents and POST /api/sendPrompt. The poster, and the author of an unofficial TypeScript SDK built on it, both call it "an undocumented internal API, not an official Cursor product": routes and storage paths may change after an update, the token should be treated like a password, and port 1340 should never be exposed to the internet.

Caveats before you build on it. Anything that rides on the app session or the gateway can break with an app or computer update (the docs say an update rebuilds the computer and removes installed packages), and you should read Cursor's terms for your plan before automating an account this way. For personal workflows it is the most capable option there is; for a product other people depend on, wait for an official API or design around the webhook and MCP surfaces.

We searched X for "grok bot" together with api, cli, mcp or sdk and read 800 posts (newest first, 40 pages, collected in 2026). The search filled our page cap in 2.49 days, which works out to about 321 matching posts a day; the one complete UTC day in the window had 305.

Reading the numbers. "API" is the broadest word (it also covers API keys and the xAI API), so its 41.6% is an upper bound on people asking for a Grok Bot API specifically. MCP at 28.4% is the sharper signal: people want Grok Bot to sit in the same tool mesh as their other agents. Claude or Claude Code is named in 24.2% of posts, Codex in 10.0% and Cursor in 10.1%, which matches the forum threads: the common goal is handing work between Grok Bot and a coding agent. Only 15.9% of posts carry a question mark; most are people sharing a workaround or a template.

Engagement is thin and skewed. The median post had 1 like and 168 views; 34.9% had no likes, while the top 10% passed 4,729 views. English made up 58.9% of posts, Chinese 14.5% and Japanese 9.2%.

Most "Grok Bot API" searches come from people who want Grok's reasoning over live X posts inside their own app, bot or agent. That does not need Grok Bot. The xAI API at https://api.x.ai/v1 serves the same Grok models with an xAI API key (our guide to getting a Grok API key covers the console steps). docs.x.ai lists grok-4.7 as the recommended model for chat and code, at $2.00 per million input tokens and $6.00 per million output tokens below 200k prompt tokens. The OpenAI-compatible endpoint is POST https://api.x.ai/v1/chat/completions; xAI's reference calls it the stateless predecessor of the Responses API and recommends Responses for new integrations, so treat Chat Completions as the quick start.

Where the X data comes from. Grok models have no live data unless you give it to them. You have three options. xAI's server-side X Search tool is billed at $5 per 1,000 posts fetched and $10 per 1,000 user profiles on top of tokens (docs.x.ai/developers/tools/x-search). The official X API pay-per-use rate card charges $0.005 per post read (docs.x.com/x-api/getting-started/pricing). twitterapi.io charges 15 credits per tweet returned, $0.15 per 1,000 tweets, with a 15-credit ($0.00015) minimum per request and no X account needed. Per 1,000 posts that is $5 against $0.15, about 33x apart.

The pattern. Fetch the posts yourself with /twitter/tweet/advanced_search (any X search operator, queryType=Latest, follow next_cursor), format them into a compact prompt, and send that to grok-4.7. You control exactly which posts the model sees, the cost of the data is fixed before the model runs, and the same fetch works for Claude, GPT or a local model. The full runnable script is at the end of this page.

Writing back to X. If your agent also needs to post, reply or follow, twitterapi.io has write endpoints that act through an authenticated session: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, then each action such as /twitter/create_tweet_v2 costs $0.002, billed per HTTP 200 call. Every call acts as that account, so X can rate-limit, lock or suspend it; keep a human pace and expect to log in again when the session expires.

To size the pipeline we pulled one /twitter/user/last_tweets page (20 posts, newest first) from five official accounts: @xai, @grok, @cursor_ai, @XDevelopers and @bot. We did not call the xAI API in this study, so the model cost below is an estimate from the prompt size (characters divided by four, a common rule of thumb) at the grok-4.7 list price, with 400 output tokens assumed.

Takeaways. A full page of 20 posts made a prompt of roughly 938 tokens (median), and the whole run, data plus an estimated Grok summary, came to about $0.0073. The data is the smaller half: at these prices the model tokens cost more than the posts. The @xai call returned no posts on our request and was billed only the $0.00015 request minimum, which is also what an empty polling check costs. Each call took a median 2.3 seconds end to end in our client, which includes Python start-up and the shared rate-limit spacing our study tooling adds, so it overstates the API's own latency.

Scaling it. Polling one search every 60 seconds for a month is 43,200 checks; if most find nothing, the floor is $6.48 a month, or $1.30 at a five-minute interval. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days) and the rate limit is 0.2 requests per second before the first payment and 20 after it.

Question. What do people on X ask for when they look for a Grok Bot API, and what does the do-it-yourself pipeline cost per run? Query. "grok bot" (api OR cli OR mcp OR sdk) -filter:retweets on /twitter/tweet/advanced_search with queryType=Latest, 40 pages; plus one /twitter/user/last_tweets page each for @xai, @grok, @cursor_ai, @XDevelopers and @bot. Window. The newest 2.49 days of matching posts at collection time (collected in 2026). Sample. 800 unique posts and 80 timeline posts, 45 requests, about $0.13 of credits.

Method. Ask types are keyword matches on the post text (API, CLI or gbot, MCP, SDK, webhook); a post can match several, and 22.5% matched only through a handle, link or word form the patterns skip. Questions are posts containing a question mark. Prompt tokens are estimated as characters divided by four; the Grok cost uses docs.x.ai's grok-4.7 list price and an assumed 400-token answer.

What the sample cannot show. It covers two and a half days of a fast-moving topic, so the shares will drift as Grok Bot ships features. Keyword matching cannot tell a request for an API from a mention of one. The page cap means we saw the newest posts, not all of them. Latency was measured in our client, not at the API.

Privacy. Search authors are mostly private individuals: we keep aggregates and de-identified rows only (no ids, links, text or handles) and do not name or quote them. Only official organization accounts are named.