WordPress + Telegram: publish posts with proof
You hit “Publish,” then you second-guess everything. Did the post actually go live, or did WordPress swallow it because of one weird character, a permissions issue, or a flaky integration?
This WordPress Telegram automation hits content managers hardest, but agency owners and marketing generalists feel it too. You get a clear success or failure confirmation so you stop refreshing the site, re-posting “just in case,” or finding mistakes after your audience already has.
Below you’ll see how the workflow builds a safe XML-RPC request, publishes via HTTP, and validates the response so you can trust the outcome.
How This Automation Works
The full n8n workflow, from trigger to final output:
n8n Workflow Template: WordPress + Telegram: publish posts with proof
flowchart LR
subgraph sg0["Manual Flow"]
direction LR
n0@{ icon: "mdi:swap-vertical", form: "rounded", label: "Settings", pos: "b", h: 48 }
n1@{ icon: "mdi:play-circle", form: "rounded", label: "ManualTrigger", pos: "b", h: 48 }
n2@{ icon: "mdi:cog", form: "rounded", label: "Success", pos: "b", h: 48 }
n3@{ icon: "mdi:cog", form: "rounded", label: "Error", pos: "b", h: 48 }
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>PrepareXML"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>PostRequest"]
n6@{ icon: "mdi:swap-horizontal", form: "rounded", label: "IsSuccessful", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "HandleResponse", pos: "b", h: 48 }
n0 --> n4
n4 --> n5
n5 --> n7
n6 --> n2
n6 --> n3
n1 --> n0
n7 --> n6
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n1 trigger
class n6 decision
class n5 api
class n4 code
classDef customIcon fill:none,stroke:none
class n4,n5 customIcon
The Problem: Publishing Without Confirmation Is Stressful
Publishing content should be boring. Instead, it turns into a tiny crisis every time you’re posting under time pressure, using a form, or pushing posts from another tool into WordPress. The worst part is the uncertainty: the request can fail quietly, or “succeed” while mangling formatting because a special character wasn’t escaped properly. Then you spend another 10 minutes checking the post, fixing quotes, re-uploading images, and explaining to a client why the link they shared shows a broken draft. Multiply that across a week and it’s a real time tax.
It adds up fast. Here’s where it breaks down in real life.
- You publish, then you manually verify on mobile and desktop because you don’t trust the pipeline.
- One unescaped character can break XML-RPC payloads, which means posts fail or arrive with weird formatting.
- When the WordPress node or a connector stops working, your “automation” becomes a frantic workaround.
- You don’t get a clean pass/fail signal, so teams re-submit posts and accidentally duplicate content.
The Solution: Publish via HTTP and Get a Clear Result
This workflow publishes to WordPress using XML-RPC through n8n’s generic HTTP Request node, then validates the response so you know if it worked. It starts with a trigger, pulls in your blog settings (URL, username, and an application password), and builds a properly formatted XML payload in a dedicated step that escapes special characters. Next, n8n sends the XML-RPC request as an HTTP POST to your WordPress endpoint. The reply comes back as XML, gets converted into JSON, and a simple validation check decides which path to take. If publishing succeeded, you route to a success endpoint. If it didn’t, you route to a failure endpoint so you can notify the right place (like Telegram) and stop guessing.
The workflow begins when you launch it (manually in the base version). It then prepares the publish request, sends it to WordPress, and inspects WordPress’s response for an unambiguous success or error. Finally, it routes to a success/failure outcome you can connect to Telegram notifications.
What You Get: Automation vs. Results
| What This Workflow Automates | Results You’ll Get |
|---|---|
|
|
Example: What This Looks Like
Say you publish 5 posts a week and you currently do a “sanity check loop” each time: submit the post, refresh WordPress, open the public URL, then fix anything odd. That’s maybe 10 minutes per post, so close to an hour a week in checking alone. With this workflow, you trigger the publish request once and get a clear pass/fail outcome; the actual submit takes a minute, then you wait for the response. Realistically, you’re down to a couple minutes per post, mostly for content review, not technical verification.
What You’ll Need
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- WordPress site to publish posts via XML-RPC
- Telegram to receive success/failure confirmations
- WordPress application password (create it in your WordPress user profile)
Skill level: Intermediate. You will paste credentials, edit a few fields, and be comfortable tweaking one code step if your payload needs extra fields.
Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).
How It Works
A publish request kicks it off. In the base workflow, you start it with a manual trigger. Many teams swap this for a form submission or a schedule once they’re happy with the output.
Your blog settings are loaded. The workflow sets your target URL, username, and app password in one place, so you’re not hunting through nodes later when something changes.
The XML payload is built safely. A code step prepares the XML-RPC request and properly escapes special characters, which is where a lot of “random” posting failures come from, frankly.
WordPress replies, and the workflow validates the outcome. n8n sends the HTTP POST, parses the XML response, then uses a simple condition to route to success or failure. You can connect those endpoints to Telegram so you get a clean message right after each publish attempt.
You can easily modify the trigger to accept post content from a form or a sheet based on your needs. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Manual Trigger
This workflow starts on demand, so the manual trigger is used to initiate the XML-RPC publishing flow.
- Add or confirm the Manual Launch Trigger node at the start of the workflow.
- Connect Manual Launch Trigger to Configure Blog Values to pass control into your configuration step.
Step 2: Connect WordPress Blog Values
Set the WordPress endpoint, user credentials, and post content in Configure Blog Values so downstream nodes can build the XML payload.
- Open Configure Blog Values and add the following fields under Assignments:
- Set wordpressUrl to
yourblog.wordpress.com. - Set wordpressUsername to
[YOUR_ID]. - Set wordpressApplicationPassword to
[CONFIGURE_YOUR_TOKEN]. - Set contentTitle to
This is a demo titleand contentText toThis is the main text..
=https://{{ $('Configure Blog Values').item.json.wordpressUrl }}/xmlrpc.php.Step 3: Set Up the XML Payload Builder
The XML-RPC payload is constructed in Build XML Payload using your inputs from Configure Blog Values.
- Open Build XML Payload and keep Mode set to
runOnceForEachItem. - Confirm the code reads input fields like
wordpressUsername,wordpressApplicationPassword,contentTitle, andcontentText. - Verify the script writes the final payload to
$input.item.json.xmlRequestBodyfor downstream use.
Step 4: Configure XMLRPC Request and Response Validation
Send the XML payload to WordPress and validate the response to route success or failure.
- In Send XMLRPC Request, set URL to
=https://{{ $('Configure Blog Values').item.json.wordpressUrl }}/xmlrpc.php. - Set Method to
POST, enable Send Body, and set Body to={{ $json.xmlRequestBody }}. - Set Content Type to
rawand Raw Content Type totext/xml, and ensure a header Content-Type with valuetext/xmlexists. - Connect Send XMLRPC Request to Parse XML Reply to parse the XML response.
- In Validate Response, keep the condition that checks
={{ $json.methodResponse.params.param.value }}with the exists operator. - Route the true output to Success Endpoint and the false output to Failure Endpoint.
methodResponse.params.param.value, which is why Validate Response checks that this value exists.Step 5: Test and Activate Your Workflow
Run the workflow manually first to confirm your credentials and XML payload work, then activate for reuse.
- Click Execute Workflow to trigger Manual Launch Trigger and run through the XML-RPC flow.
- Confirm Success Endpoint receives data when the post publishes, or inspect Failure Endpoint if it does not.
- Check your WordPress site to ensure the post appears with the correct title and content.
- Once validated, toggle the workflow to Active for production use.
Common Gotchas
- WordPress application passwords can be revoked or blocked by security plugins. If publishes suddenly fail, check your WordPress user profile first, then any security/firewall logs.
- If you add Wait nodes or depend on external processing before publishing, response timing can vary. Bump up the wait duration if downstream nodes fail on empty responses.
- The payload builder is only as good as the content you feed it. Curly quotes, HTML fragments, and pasted content from Google Docs can create messy markup, so sanitize content before it hits the “Build XML Payload” step.
Frequently Asked Questions
About 30 minutes if you already have a WordPress app password.
No. You can run it as-is, but light edits to the payload step are helpful when your post fields get more complex.
Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in WordPress hosting costs (already paid for in most cases) and any Telegram bot setup you use for notifications.
Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.
Yes, and it’s a common upgrade. Replace the Manual Launch Trigger with a Schedule Trigger, then connect the Success Endpoint and Failure Endpoint to a Telegram message node so you get a “published” or “failed” alert instantly. You can also extend the “Configure Blog Values” step to include categories, tags, or status (draft vs publish) depending on how you want WordPress to behave.
Usually it’s an app password issue or XML-RPC being blocked. Regenerate the WordPress application password, update it in the “Configure Blog Values” step, and confirm your site still allows XML-RPC requests (some security plugins disable it). Also check the WordPress URL you’re posting to, because one extra slash or a wrong endpoint can look like “bad credentials.” If failures happen only under load, you may be hitting rate limits or a host-level firewall rule.
On n8n Cloud Starter, you can usually handle a few thousand executions per month, which is plenty for most publishing schedules. If you self-host, there’s no execution limit; it depends on your server and how fast WordPress responds. This workflow is lightweight since it’s basically one request, one parse, and one conditional check per post.
Often, yes. This approach is more resilient when a “native” WordPress connector is flaky, because you control the HTTP request and the success check. n8n also handles branching logic cleanly, so success and failure can trigger different Telegram messages without awkward workarounds. Zapier or Make can still be fine for simple posting, but you may end up paying more once you add filters, retries, and error routing. If you’re unsure, Talk to an automation expert and we’ll sanity-check your exact use case.
Once you have a publish request you can actually trust, content ops gets quieter. The workflow handles the “did it work?” loop so you can move on.
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.
