How to Build a Twitter (X) to Discord Bot in 2026

The bot has four parts: a source of new tweets, a memory of which tweets it already posted, a formatter that turns a tweet into a Discord message, and a single HTTP POST to a Discord webhook URL. The memory and the formatter are a few lines each. The POST is one call. The only real decision is the source, and there are two reasonable ones.

Path 1, polling. A script runs every minute or every five minutes, asks the X API for posts newer than its last run, and relays what is new. On twitterapi.io the right call is /twitter/tweet/advanced_search with a query such as (from:vercel OR from:github) since_time:1760000000 and queryType=Latest, because it returns only the posts you have not seen (an idle pass returns an empty list and costs the $0.00015 minimum). A seen set of tweet IDs catches the overlap you deliberately re-read at the boundary.

Path 2, push. You register a filter rule once (/oapi/tweet_filter/add_rule, the same from: syntax, checked every interval_seconds), point your account's webhook URL at an HTTPS endpoint you host, and the API POSTs matching tweets to it as they are found. Your receiver answers 200 within a second and forwards each tweet to Discord. Nothing to schedule, but something to host.

Rule of thumb from the data below: these accounts post 0.3 to 5 times a day each, so a 60-second poll is already far more often than anything happens. Start with Path 1 at 60 seconds (or 5 minutes if a few minutes of delay is fine, which cuts the bill by about 80%), and move to Path 2 when you want sub-minute delivery for many rules without running a scheduler. If what you watch is a fixed list of accounts and seconds matter, the Twitter Stream product pushes their posts to a webhook on a flat monthly plan instead of per call.

In Discord, open the target channel's settings, go to Integrations, create a webhook and copy its URL. The URL has the form https://discord.com/api/webhooks/<id>/<token>, and per Discord's webhook documentation, executing a webhook is POST /webhooks/{webhook.id}/{webhook.token} with no bot token and no OAuth: the token in the URL is the credential. Treat it like a password (environment variable, never a repository).

What you can send. The JSON body needs at least one of content, embeds, components, file or poll. content is plain text up to 2,000 characters. embeds is an array of up to 10 embed objects; an embed's description can hold 4,096 characters, its title 256, with a combined cap of 6,000 characters across all embeds in one message (Discord's message documentation). username and avatar_url override the webhook's display name and avatar per message, which is a neat way to show the X account's name on each post. allowed_mentions controls what the message is allowed to ping; {"parse": []} suppresses every mention, which you want for a feed that relays other people's text. flags is a bitfield; SUPPRESS_EMBEDS is 1 << 2 and SUPPRESS_NOTIFICATIONS is 1 << 12.

Two query parameters matter. wait=true makes Discord wait for the message to be created and return it as JSON (useful while debugging); without it a success is 204 No Content. thread_id posts into a thread of the webhook's channel instead of the channel itself.

Run the smoke test below before writing any X code. If the first curl prints 204, the Discord half is done.

The full Python bot is at the end of this page; this section explains its three decisions, and gives the same bot in Node.

Decision 1: search, not the timeline endpoint. The obvious call for "new posts from @vercel" is /twitter/user/last_tweets, but it returns a full page of the account's latest 20 posts on every call, and tweet endpoints bill per tweet returned: 15 credits each, so a page is $0.003 whether or not anything is new. Polled every 60 seconds that is 1,440 pages, $4.32 a day, per account. /twitter/tweet/advanced_search with a since_time: operator returns only posts created after that Unix timestamp. In our sample 98.8% of 60-second windows held nothing new for the whole 10-account feed, so almost every pass returns an empty list and costs the $0.00015 minimum: $0.216 a day for the floor, plus $0.00015 per new post actually returned. Use last_tweets once, for the initial backfill, if you want the channel to start with history.

Decision 2: one query for all accounts. from: operators can be joined with OR, so ten accounts are one request: (from:vercel OR from:github OR from:Docker ...) since_time:1760000000. Keep the whole query under 512 characters, which is roughly 25 handles; beyond that, split into several queries per pass. A keyword feed is the same call with a different query, for example "vercel" lang:en -filter:replies min_faves:20, which is what the X_QUERY variable in the script switches to.

Decision 3: overlap plus a seen set, not a precise cursor. Clock skew and indexing delay mean a post created at 12:00:59 can show up in the search a little later. The script therefore re-reads the last 120 seconds before its previous run (OVERLAP) and drops anything whose ID is already in state["seen"], which it keeps at 2,000 IDs in a small JSON file. The overlap costs nothing when idle (the same minimum charge) and makes missed posts a non-issue. New posts are sorted oldest first before posting so the channel reads in order.

Scheduling. python twitter_to_discord.py does one pass and exits, so a crontab line * * * * * cd /srv/feed && python twitter_to_discord.py is the 60-second version and */5 * * * * the 5-minute one; --loop 60 keeps it running in a container instead. GitHub Actions also works for the 5-minute version (its schedule granularity is 5 minutes), with the state file committed or cached between runs.

Reposts. When we compared a from: search with the timeline endpoint for the same accounts and week on another study, the search returned every post except reposts. Reposts were 4.6% of this sample, so most feeds will not miss them; if yours must include them, poll /twitter/user/last_tweets for that one account and pay the $0.003 page, or run the Path 2 rule and see what it delivers.

The Node version below is the same algorithm in about 50 lines with Node 18's built-in fetch, one pass per run; schedule it the same way.

Path 2 moves the polling to twitterapi.io's side. You create a rule, the API evaluates it every interval_seconds, and each batch of matching tweets is POSTed to the webhook URL configured on your account. Three facts from the endpoint documentation shape the code.

The rule. POST /oapi/tweet_filter/add_rule takes tag (your label, up to 255 characters), value (the filter, same from: and keyword syntax as the search, up to 255 characters, so about 10 to 12 handles per rule) and interval_seconds (how often it is checked: minimum 0.05, maximum 86,400, default 60). It returns rule_id, status and msg. A new rule is not active. You must call POST /oapi/tweet_filter/update_rule with every field again (rule_id, tag, value, interval_seconds) and is_effect: 1. GET /oapi/tweet_filter/get_rules lists what you have; the dashboard can edit rules too.

The push. Each delivery is a JSON POST with event_type ("tweet"; the dashboard's test button sends "test_webhook_url"), rule_id, rule_tag, rule_value, timestamp in milliseconds and a tweets array of the same tweet objects advanced_search returns (id, text, url, createdAt, author.userName, likeCount and so on). The request carries your own API key in an x-api-key header, and there is no HMAC signature, so compare that header with your key in constant time and answer 401 otherwise. The push times out after one second and is not retried: answer 200 first and do the Discord call on a worker thread or queue.

The bill. Every evaluation of the rule costs at least $0.00015 (15 credits), found something or not, and each matched tweet delivered costs $0.00015. A rule checked every 60 seconds therefore has the same $0.216-a-day floor as Path 1 at 60 seconds; at interval_seconds: 5 it is 17,280 checks, $2.59 a day ($77.76 a month), which is what sub-minute delivery costs.

The receiver below is complete: run it once with CREATE_RULE=1 to create and activate the rule, deploy it anywhere with a public HTTPS URL (a small VM, Railway, Render, or a serverless function kept warm so cold starts stay under the one-second budget), and paste that URL into the twitterapi.io dashboard's webhook settings. It imports format_message from the polling script so both paths post identical messages.

Both scripts build the same message: a bold header with the account's display name and handle, the post text, and the post URL on its own line (Discord unfurls a link in content into a preview card, which is why we keep the link whole). The lengths that result come from the study.

Most posts fit easily, a few never will. Across 2,000 posts the median formatted message was 285 characters and the 95th percentile 453. But 466 posts (23.3%) were longer than 280 characters, because long-form posts return their full text in text, and the longest raw text was 5,263 characters. Two posts out of 2,000 (one each from @OpenAIDevs and @discord) produced a formatted message above Discord's 2,000-character limit, 5,335 characters at most. Discord rejects those with a 400, so the formatter cuts the text to the room left after the header and the URL and appends an ellipsis. Never cut the URL: the preview card and the click-through are the feed's value.

If you want more room, use an embed. An embed description holds 4,096 characters, which would have fit every post in this sample but the two longest, and title or author can carry the handle. The trade-off is that embeds do not auto-unfurl the linked post, so you render the text yourself. The curl example in Step 1 shows the shape.

Never let a relayed post ping your server. Tweet text can contain @everyone or @here, and Discord would honor it. allowed_mentions: {"parse": []} tells Discord to parse no mention types at all; both scripts send it on every message. If you do not want push notifications for the feed either, add flags: 4096 (SUPPRESS_NOTIFICATIONS, 1 << 12).

Rate limits. Discord's rate-limit documentation describes per-route limits reported in X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-RateLimit-Reset-After and X-RateLimit-Bucket headers, a 429 body with message, retry_after (seconds) and global, and a global limit of 50 requests per second for bots. It does not publish the per-webhook number; developers commonly report about 30 requests per 60 seconds per webhook, and the headers on your own responses are the authority. Both scripts sleep on retry_after after a 429 and pause two seconds between posts. For a feed like the one measured here that margin is enormous: the busiest clock hour across all 10 accounts held 8 posts, and the busiest minute 3. The one hard rule from the docs: if the webhook returns 404 it has been deleted, stop calling it, because repeated attempts lead to temporary restrictions.

To size the bot we pulled the 200 most recent posts (10 pages of /twitter/user/last_tweets, replies excluded by default) from each of 10 organization accounts people put in Discord feeds: developer platforms (@vercel, @github, @Docker, @CloudflareDev, @OpenAIDevs), hardware and gaming (@nvidia, @PlayStation, @Xbox), plus @discord and @NASA. 100 requests, 2,000 posts, $0.30 in API reads.

Nobody posts much. The accounts post between 0.3 and 5.0 times a day; @PlayStation is the only one above 3. The 200 posts spanned 40 days for @PlayStation and 713 days for @discord. Combined, in the 38-day window all ten accounts cover, the feed would have relayed 707 posts, 18.5 a day, with a peak of 8 in a single clock hour and never more than 3 in one minute.

Gaps are hours, not minutes. The median gap between consecutive posts ranged from 1.5 hours (@Xbox) to 2.1 days (@discord), and the 90th-percentile gap from 16 hours to over 6 days. The longest silence in the sample was 40 days (@discord). A bot that assumes a steady trickle will spend nearly all of its passes finding nothing; a bot that sleeps for an hour after each post will still rarely miss anything, but will deliver late. The 60-second poll with a since_time: cursor is the compromise: cheap when idle, prompt when something lands.

What kind of posts. 84.1% were original posts, 11.3% quotes and 4.6% reposts; replies were 0% because the default timeline call excludes them. @CloudflareDev (27.5% quotes), @discord (22.5%), @nvidia (22.0%) and @OpenAIDevs (21.5%) quote the most; @OpenAIDevs also reposts the most (15.5%). If your channel should not relay quotes, check quoted_tweet and skip; a from: search already omits reposts.

"Empty polls" is the share of 60-second or 5-minute windows across each account's sample span that contained no new post, which is the share of passes that would return an empty list and cost the $0.00015 minimum. The combined row uses the 38-day window in which all ten accounts have data.

Posts cluster in the US working day. 92.2% of the 2,000 posts were created between 12:00 and 23:59 UTC, and 38.3% in just three hours, 16:00 to 18:59 UTC (766 posts). The six quietest hours, 03:00 to 08:59 UTC, held 36 posts in total, 1.8%. Every account's busiest hour sits between 13:00 and 21:00 UTC. For a bot this means two things: a 60-second poll overnight is almost pure floor cost (you can drop to 5 minutes between 00:00 and 12:00 UTC and lose little), and Discord's rate limit is irrelevant even at the afternoon peak.

Cost per day for this 10-account feed (about 19 posts a day), using twitterapi.io's published prices: 15 credits per tweet returned ($0.15 per 1,000), a 15-credit minimum per request ($0.00015), $1 = 100,000 credits; and the official X API pay-per-use rate card at $0.005 per post read (docs.x.com), which is about 33x more per 1,000 posts ($5 vs $0.15).

The two official-API rows bracket the real answer: the official rate card prices each post read, so a tight since_id keeps it to new posts only, but a timeline-style call that returns recent posts every minute is billed for every one of them, and you need the paid developer account before the first call. On twitterapi.io the cost of asking is the $0.00015 minimum, and because 98.8% of passes return nothing, the floor is the bill. Plans with bonus credits are on the pricing page.

Discord returns 400. The body violated a limit: content over 2,000 characters, more than 10 embeds, or an embed field over its cap. Log the length of what you sent; the formatter on this page cuts text to fit.

Discord returns 401 or 404. The webhook URL is wrong or the webhook was deleted in the channel settings. On 404, stop posting to that URL, create a new webhook, and update the environment variable.

Discord returns 429. Read retry_after from the JSON body (seconds) and sleep that long before retrying; check X-RateLimit-Remaining on earlier responses to see how close you were. Spacing posts two seconds apart keeps a burst of relayed posts under the limit.

The message pinged @everyone. You sent a message without allowed_mentions. Add {"parse": []} to every POST.

Posts arrive twice. Two overlapping sources (two rules, or a rule plus a poll) delivered the same tweet, or the state file was not written. De-duplicate on id, and make sure the process can write discord-feed-state.json where it runs.

Posts arrive out of order or late. Sort new posts by createdAt (format %a %b %d %H:%M:%S %z %Y, not ISO 8601) before posting. Late arrivals within a couple of minutes are normal; that is what the 120-second overlap is for.

The poll finds nothing for an account that clearly posted. Reposts are not returned by a from: search. Check the handle with /twitter/user/info (handles change), and confirm the post is not a reply if your query has -filter:replies.

HTTP 429 from twitterapi.io. Accounts that have never paid are limited to 0.2 requests a second (20 once paid). A single poll per minute is far below that; if you poll several queries per pass, space them out.

The filter rule never fires. New rules are inactive until update_rule is called with is_effect: 1 and every other field. Also check that the dashboard webhook URL is HTTPS and answers 200 in under a second; use the dashboard's test button and look for the test_webhook_url event in your logs.

The receiver gets the push but Discord never shows it. The worker thread is doing the Discord call; if the process is a serverless function it may be frozen right after returning 200. Keep a minimum instance warm, or hand the batch to a queue the function does not own.

Question: how many posts per hour and per day would a Twitter-to-Discord feed of typical organization accounts actually relay, how long are the gaps, what share of 60-second and 5-minute polls would find nothing, when in the day do posts land, and how many posts would exceed Discord's 2,000-character limit once formatted.

Accounts: 10 public organization accounts: @vercel, @github, @Docker, @CloudflareDev, @OpenAIDevs, @nvidia, @PlayStation, @Xbox, @discord and @NASA.

Method: /twitter/user/last_tweets with the default includeReplies (replies excluded), 10 pages of 20 per account, newest first: 100 requests, 2,000 posts, collected in 2026 through a rate-limited, read-only client. For each account we measured the span from oldest to newest post, posts per day, posts per UTC clock hour, gaps between consecutive posts, the share of 60-second and 300-second windows across the span with no post, and the length of each post formatted as the Discord message the scripts on this page send (header line, text, URL). The combined feed uses the window in which all 10 accounts have data (38 days).

What the sample cannot show: 200 posts per account is a snapshot, and for the quieter accounts it reaches back more than a year, so posts per day is a long-run average that hides launch weeks. Ten organization accounts are not individuals or news accounts, which post far more often; a feed of such accounts would see shorter gaps, more multi-post windows, and a higher share of non-empty polls, though the polling floor arithmetic is the same. Replies were excluded by the default call, so the reply share is unmeasured here. The Discord webhook limits were read from Discord's documentation, and the per-webhook rate limit is not published there, so we did not test it.

Aggregates only. The accounts named are organizations; no individual's posts were analyzed. The analysis script, results and the gzip-compressed raw pages for these organization accounts are kept with the study.