X Banned Automated DMs in 2026 — How Inbound Support Teams Still Receive and Route Them — UnifyPort

If you run customer support or community management on X, the platform’s 2026 rule changes probably landed in your inbox with an ominous subject line. Auto-DMs — the classic “thanks for following, check out my product” message that fires when someone follows you — are now explicitly prohibited. Bulk DMs and cold-outreach DMs sent through automation are off the table. And any programmatic use of the DM endpoint for marketing purposes is grounds for losing API access entirely. Stack that on top of the February 2026 switch to pay-per-use pricing, where reading a single DM is a billable request, and the takeaway for a small team feels blunt: outbound automation on X is now both restricted and metered.

Here’s the part that gets lost in the panic. If your team uses X to receive messages — order questions, support tickets, mentions that need a human reply — almost none of the 2026 crackdown is aimed at you. The new rules target one specific behavior: unsolicited, automated outbound DMs at scale. Receiving the messages people deliberately send you, and getting them in front of a human quickly, is a different problem with a different answer.

What actually changed

It helps to be precise about the new restrictions, because the headline (“X cracks down on DM automation”) is broader than the rules themselves.

The prohibited behaviors are all forms of unsolicited outbound: auto-DMs triggered by a follow, bulk DM campaigns, cold outreach to people who never messaged you first, and any automated DM sent for marketing. X also tightened its data-handling language — services must get express, informed consent before storing non-public DM content, and must not expose DM content to anyone not authorized to see it.

On the pricing side, the free API tier closed to new developers in February 2026, and everyone else moved to pay-per-use. The rates have shifted since launch, but the structure is what matters: every read is a request, and every request has a price. For a team that monitors DMs by polling — checking the API every 30 seconds to see whether anything new arrived — that means a meter that runs continuously, whether ten messages came in or none.

So the official path now carries two distinct costs for an inbound team: a policy cost (high-frequency programmatic access draws scrutiny under the automation rules) and a metered cost (every poll is billable). Neither has anything to do with the messages your customers are actually sending you.

Why inbound is a different problem

Reframe what your support team actually does. A customer DMs you a question. A human reads it, types a reply, and sends it. There is nothing automated about the outbound message — a person wrote it — so the auto-DM ban simply doesn’t apply. The only thing you genuinely need to automate is the delivery of the incoming message to your team, fast enough to answer within your SLA.

That’s an inbound routing problem, not an outbound automation one. And the cleanest way to solve it is the opposite of polling: instead of your service repeatedly asking X “anything new yet?”, the message gets pushed to you the instant it arrives. No polling loop means no continuous read meter and no high-frequency access pattern for the automation rules to flag. You receive what people send you, a human replies, and you never originate an unsolicited DM.

Receiving X DMs and mentions through one webhook

UnifyPort connects your X account and pushes inbound DMs and mentions to your own webhook endpoint as they happen. You register the endpoint once, subscribe to the events you care about, and inbound activity arrives as a normalized message.received event — the same shape you’d get for WhatsApp, Telegram, LINE, TikTok, or Zalo, so a multi-channel support desk reads from one schema instead of six provider formats.

When you create the webhook, you list subscribed_events (use ["*"] for the full catalogue, or name message.received and account.status.updated explicitly) and set a signing_secret. Every delivery is then stamped with an HMAC-SHA256 signature your handler verifies before trusting the body. A delivered DM looks like this:

{
  "event": "message.received",
  "data": {
    "account_id": "acct_x_support",
    "provider": "twitter",
    "chat_id": "dm_8841f0",
    "sender": "user_3a91c7",
    "message": {
      "id": "x_msg_5f2a91",
      "type": "text",
      "text": "Hey — did my order ship? The tracking link 404s",
      "reply_token": "rt_9b1c7e..."
    },
    "timestamp": 1750939200
  }
}

Your receiver verifies the signature, then routes the message wherever your team triages — a Slack channel, a helpdesk, a database:

const crypto = require("crypto");

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-UnifyPort-Signature");
  const expected = crypto
    .createHmac("sha256", process.env.SIGNING_SECRET)
    .update(req.body)
    .digest("hex");
  if (signature !== expected) return res.sendStatus(401);

  const { event, data } = JSON.parse(req.body);
  if (event === "message.received" && data.provider === "twitter") {
    routeToTriage({
      chatId: data.chat_id,
      from: data.sender,
      text: data.message.text,
      messageId: data.message.id,
    });
  }
  res.sendStatus(200);
});

Notice what this handler does not do: it never sends a DM. It receives, verifies, and routes. When your agent writes a reply, it goes out through UnifyPort’s normalized send endpoint as a human-authored message — not an auto-DM, not a bulk campaign. (One X-specific note: the quoted-reply reply_to.reply_token field is WhatsApp-only today, so for X you send a plain reply rather than a threaded quote; the inbound event still carries the token for the platforms that support it.)

Because events are pushed and missed events aren’t replayed by polling, your team sees inbound activity within seconds of it being sent — typically faster than a 30-second poll cycle, and without the read meter running in the background on quiet days.

The practical next step

The 2026 rules drew a clear line: X doesn’t want automated outbound DMs flooding people’s inboxes, and it now charges for programmatic reads. An inbound support team sits entirely on the right side of that line — every reply is written by a person, and there’s no reason to poll the API at all. If you’re currently running a polling service against X just to know when a customer wrote in, the switch to a push-based webhook removes both the policy exposure and the metered reads in one move.

Connect your X account to a unified inbound webhook, point it at an endpoint that verifies the signature and routes by chat_id, and let your team go back to doing the one thing the new rules never restricted: answering the people who message them.