A Discord webhook is a single URL that lets PostRSS publish your RSS feed into one channel — no bot, no OAuth, no app review. Create it in under two minutes, paste it into PostRSS, and every new article posts itself.
A webhook, in Discord’s sense, is a unique URL tied to one specific channel in one specific server. Any HTTP request sent to that URL, carrying a message or an embed, gets posted into that channel. There is no bot invitation, no OAuth login flow, and no ongoing authentication beyond possessing the URL.
That is the entire mechanism, and it explains both its appeal and its one rule. Whoever holds the URL can post into that channel — which is why the URL should be treated as a credential, covered further down — but equally, holding it grants nothing else. A webhook cannot read messages, cannot see your member list, cannot join voice, cannot moderate, and cannot post into any other channel. It is the narrowest form of access Discord offers.
The URL looks like https://discord.com/api/webhooks/1234567890/AbCdEf…. The first number identifies the webhook; the long string after it is the token that authorises posting.
Facebook, X and LinkedIn are built around public pages and profiles designed to be discovered and followed, so each offers a consent screen that grants an outside tool permission to publish on your behalf.
Discord is architected differently. A server is a private, invite-based space split into channels, and Discord’s product philosophy has consistently favoured giving owners granular control over exactly what gets posted where, rather than a single “connect a feed” toggle that publishes on the server’s behalf.
So instead of a purpose-built RSS connector, Discord exposes a general-purpose primitive. It is more flexible than a feed switch would be, but it shifts the work of turning “new blog post” onto whatever sits on the other end of the URL — which is precisely the job PostRSS does. If you would rather read about the destination side of this — choosing the channel, what members see, how to keep it welcome — see autoposting to a Discord channel.
The whole process happens inside Discord and takes under two minutes. You need the Manage Webhooks permission, which server owners and most admin roles already have. No developer account, no app submission, no review period.
Decide which channel automated posts should land in, then click the gear icon beside its name — or right-click the channel and choose Edit Channel.
In the settings menu on the left, click Integrations. If the server already has webhooks, they are listed here; if not, you are offered the option to create one.
Click Webhooks, then New Webhook. Discord generates one with a default name and avatar. Rename it to something you will recognise later — “PostRSS”, “Blog”, “Releases” — because a server that accumulates several webhooks over a year becomes impossible to audit if they are all called “Spidey Bot”.
The name and avatar you set here are what members see on each posted message, so this doubles as a branding decision. Many publishers upload their own logo at this point.
Click Copy Webhook URL. This string is the credential you will paste into PostRSS, and it is all any tool needs to post into that channel.
Click Save Changes before leaving the panel. This is the step people skip, and a webhook that was never saved simply will not exist when you try to use it.
In PostRSS, each destination is a Target. Paste the webhook URL to add the channel as one, then point a feed at it. On WordPress the feed is usually your domain followed by /feed/, and every category and tag has its own — /category/releases/feed/, for instance.
PostRSS sends the item’s title and a link to the original page. Discord then builds an embed card from that page’s open-graph tags — the image, the title and the description your site already declares for social sharing. The result is a card with a thumbnail and a summary rather than a bare link dropped into chat, and the difference is immediately visible to anyone reading the channel.
The practical consequence is that the appearance of your Discord posts is controlled by your website, not by PostRSS. If an embed arrives with no image, the article is missing an og:image, or the image exceeds Discord’s size limits, or a CDN rule is blocking Discord’s fetcher. Fixing it at the source fixes every network at once, because Discord, Telegram, Facebook, LinkedIn and X read the same tags.
Discord caches embeds aggressively. If you correct an image and the old one keeps appearing, that is the cache rather than the automation; it clears on its own, and a changed image URL bypasses it immediately.
This is the one genuine risk of the webhook model, and it is easy to manage once stated plainly: anyone who obtains the URL can post into that channel as your webhook, with the name and avatar you configured.
They cannot read anything, cannot reach other channels and cannot touch your server’s settings — the blast radius is one channel’s message stream. But a leaked webhook posting spam under your project’s logo is still a bad afternoon.
Three habits cover it. Do not paste the URL into public issues, screenshots, support threads or a repository — webhook URLs are among the most commonly leaked secrets on public code hosts. Do not commit it to version control, even a private one. And if you ever suspect it has been seen, delete the webhook and create a new one; that is the rotation procedure, and it takes the same two minutes as the original setup.
Deleting a webhook is also the fastest possible off switch. If something goes wrong at three in the morning and you cannot get into PostRSS, removing the webhook in Discord stops publishing instantly and irreversibly, with no cooperation needed from anything else.
Webhooks are subject to rate limiting like any API endpoint, and it is worth knowing the shape of the limits even though ordinary feeds never approach them.
Discord enforces roughly 30 requests per minute per webhook, alongside a stricter per-channel limit of about 5 messages every 5 seconds shared across everything posting into that channel — other webhooks and bots included.
For a blog, shop or podcast publishing a handful of items a day, this is a non-issue. It becomes relevant in exactly two situations. The first is an initial burst: a feed that suddenly exposes many items at once, for example after a migration or a bulk import. The second is a busy channel where several integrations already post.
The fix for both is scheduling. PostRSS’s scheduling controls constrain when a Target may publish, holding items found outside the window and releasing them inside it, which spreads a burst into a sequence and keeps you clear of the per-channel limit without any manual intervention.
Check that it still exists. Open the channel’s Integrations panel and confirm the webhook is listed. Webhooks are deleted more often than people expect — during a server tidy-up, or when the channel itself is deleted or converted. Recreating one produces a new URL, which must be updated in PostRSS; the old URL will never work again.
Renaming a channel does not break a webhook — the URL points at the channel’s ID, not its name. If posting stopped at the same time, something else changed; look for a deleted webhook or a changed feed.
Unlike a bot, a webhook does not depend on a role’s posting rights, so most permission edits leave it untouched. What does break it is deletion, which anyone with Manage Webhooks can do. Note somewhere your moderators can find it that the webhook is part of the channel’s infrastructure.
That is a filter behaving as configured. Review the category, tag and keyword rules on the Target before assuming a fault.
No schedule is set on the Target. Add a publishing window; this also keeps you clear of the per-channel rate limit.
Compare the timestamps. Under five minutes is the feed-check interval working as designed — PostRSS checks every 5 minutes on every plan, every 1 minute on Enterprise. Hours means the feed is cached, and PostRSS can only read what your server serves.
Open the article and inspect its open-graph tags. Discord renders what the page declares, and its embed cache can hold an old image for a while.
A webhook belongs to exactly one channel, so publishing to three channels means three webhooks and three Targets in PostRSS. That sounds like overhead until you notice what it buys you.
Each channel is independently controlled. You can point three Targets at the same feed with three different filters, so #releases receives changelog entries, #blog receives articles and a partner’s server receives only the announcements you want shared. Deleting one webhook affects that channel alone. There is no shared permission to get wrong and no single switch that silently changes all three.
The same structure spans servers. A webhook in someone else’s server grants you nothing beyond posting into the channel they created it in — which is exactly why server owners are comfortable handing one over, and why partner announcement arrangements are far easier to set up on Discord than on most networks.
It is worth placing this mechanism next to the alternatives, because the trade-offs are genuinely different.
Facebook and LinkedIn use OAuth: you log in, grant permission, and the token can expire or be invalidated by a policy change, which is the usual cause of automation quietly stopping months later. Telegram uses a bot added as a channel administrator, so publishing depends on that bot keeping its rights. Discord’s webhook has no token expiry, no consent screen to re-approve and no role to preserve — it works until someone deletes it.
The cost of that durability is the one already covered: the URL is a bearer credential, so it needs to be kept private. For most publishers that trade is a clear win, and it is the reason Discord automation tends to be the least maintenance-heavy of the lot.
Each Discord channel you connect is one Target, and each automated message is one Task against your plan’s monthly allowance. Paid plans raise both numbers and add the other networks, and they are chosen on postrss.com rather than inside the mobile app.
The arithmetic is easy to forecast because it is entirely driven by your publishing rate: a feed producing five items a week costs roughly twenty-two Tasks a month per channel. Filtering a Target reduces that proportionally.
The same webhook idea powers more than Discord. Slack and Microsoft Teams both accept an incoming webhook scoped to one channel, and Zapier, n8n and Make treat one as a trigger that can reach almost anything downstream.
If you would rather not think about URLs at all, Telegram uses a bot instead, and Bluesky uses an app password you generate yourself. For the destination side of Discord specifically — which channel, what members see, how to keep it welcome — see autoposting to a Discord channel.
No. A bot is an application that joins your server, appears in the member list, holds roles and can read and act. A webhook is a URL that can only post into one channel, and it joins nothing.
No. There is no login step at all. The webhook URL is the only thing PostRSS holds.
Publishing stops immediately and permanently for that URL. Creating a new webhook produces a different URL, which must be pasted into PostRSS to resume.
Yes. Both are set on the webhook itself in the channel’s Integrations panel, and apply to every message it posts.
No. A webhook grants posting into one channel and nothing else — no message history, no member list, no other channels.
No. PostRSS publishes items appearing in the feed after the Target starts running.
The quickest way to understand the model is to do it: create a webhook in a quiet channel, add it to PostRSS with your narrowest category feed, and publish something. The post appears within minutes, as an embed, under the name and avatar you chose — and from then on the channel maintains itself.
