Control Discord Webhook Mentions and Pings
A visible @mention is only part of the setup. The message's allowed_mentions policy controls which written mentions can notify, and Discord still applies permissions and recipient settings. Set that policy explicitly when importing announcements, choosing a role audience or sending a test message.
Webhook defaults and explicit mention policies
Discord documents different defaults for ordinary messages and webhook or interaction messages: omitting allowed_mentions on a webhook parses user mentions only. Do not copy an ordinary-chat default into a webhook script. An explicit policy makes the intended audience visible in the exported JSON.
| Intent | allowed_mentions value | Text required |
|---|---|---|
| No mention pings | {"parse":[]} | Any mention text remains filtered |
| One role | {"parse":[],"roles":["ROLE_ID"]} | <@&ROLE_ID> |
| One user | {"parse":[],"users":["USER_ID"]} | <@USER_ID> |
| Everyone or here | {"parse":["everyone"]} | @everyone or @here |
A Components V2 message that mentions one role
Replace the example numeric ID in both places with your destination role's ID. Keep the ID as a JSON string. This example leaves user and everyone parsing disabled, so a later edit that adds a different mention does not automatically expand the configured audience.
{
"flags": 32768,
"allowed_mentions": {
"parse": [],
"roles": ["123456789012345678"]
},
"components": [
{
"type": 10,
"content": "## Event reminder\n<@&123456789012345678> Our next session is ready."
}
]
}Set the audience in DWEEB
Use the Discord message builder to preview the text and inspect JSON before delivery. If you are comparing several policies, start with one short Text Display so decoration does not obscure the audience settings. Save the reusable draft only after the destination and policy are correct.
- Add the mention to a Text Display. Use the connected server's mention picker when available, or paste the correct user or role token.
- Open Notifications in the message options. Choose the classes of mentions you intend to allow.
- For a particular role or user, expand the additional options and fill Allowed role IDs or Allowed user IDs instead of enabling that whole class.
- Review the live issues. The editor flags invalid IDs and a whole-class setting combined with an explicit list for that same class.
- Open Send and review its mention summary together with the destination. A role selected from one server does not become the corresponding role in another server.
Suppress all pings with parse: []
Use an explicit empty parse array with no allowed role or user IDs for a no-ping test. Removing the allowed_mentions field is a different instruction: it restores the webhook default. This matters when JSON is cleaned up by a script that deletes empty arrays.
For imported or model-written content, check both the Text Displays and the top-level policy. A message can look like a harmless documentation example while containing a real user token. In DWEEB, import the full payload through JSON rather than copying only its components if you also need its allowed_mentions settings.
{
"flags": 32768,
"allowed_mentions": { "parse": [] },
"components": [
{ "type": 10, "content": "Test only: @everyone <@123456789012345678>" }
]
}Silent send and no mentions solve different problems
SUPPRESS_NOTIFICATIONS disables push notifications while mentions can still create badges. Recipient notification settings also affect delivery, so an allowed mention is not a guarantee that a phone will alert. Suppressing mentions uses allowed_mentions; silent delivery uses the separate message flag.
DWEEB exposes silent send alongside the audience controls. Choose it for an intentionally quiet announcement; use an explicit no-mentions policy when people should not be targeted at all. Review both settings when reusing a reminder template for an informational post.
Why a role mention is visible but does not notify
When restoring an old message, review the policy again before Update. Discord reconstructs mentions using the edit request's policy; a missing policy does not inherit the original request's restrictions. Keep audience settings with the message design, and use the editing guide for the complete restore workflow.
- Check for the <@&ROLE_ID> token in a Text Display. Typing a role's display name or adding a role-select component is not the same as writing that token.
- Compare the role ID in the text with the Allowed role IDs field. Names can match across servers while their IDs differ.
- Review the server's role mentionability, the sending app's permissions and the recipient's notification settings.
- Check whether silent send or an explicit no-mentions policy came from the draft you reused.
Put the guide into practice
Open the exact workflow in DWEEB. Nothing posts until you review and confirm it.
Build a message with controlled mentions →