How to Automate Medium Publishing Without a New API Token

A collaborative engineering workflow where automation prepares the package before a human handoff.

If you search for a way to automate Medium publishing in 2026, you will still find tutorials that begin with the same instruction: generate an integration token, call the Medium API, and POST your article. For the approval boundary behind this workflow, compare RayLabs’ multi-agent review pipeline.

That is no longer a valid starting point for a new integration.

Medium’s current Help Center says it is not issuing new integration tokens and will not allow new API integrations. Existing tokens continue to work, but a new workflow cannot safely assume that API access exists. Medium does, however, still support its official Import a story flow, which can import a live webpage and automatically point the imported story’s canonical URL back to the original source.

That changes the architecture.

The useful question is no longer, “How do I automate a POST request to Medium?” It is:

How much of the publishing Multi Agent Review Pipeline can I automate reliably before the final Medium boundary?

For RayLabs, the answer turned out to be: almost everything that should be deterministic.

The 2026 Medium Automation Constraint

There are three materially different situations.

Situation	Viable path	Risk
You already have a legacy Medium integration token	Existing API integration may continue to work	Medium no longer supports new integrations, so treat it as legacy infrastructure
Your article already exists on a public website	Use Medium’s official Import a story flow	Imported formatting still needs visual verification
Your article exists only as Markdown or local files	Prepare a Medium-ready package, then perform a controlled manual handoff	Copy/paste and media formatting need explicit checks

The first distinction matters because many old automation tutorials describe a capability that new accounts cannot reproduce.

The second matters for SEO. If your own website is the canonical publication, Medium’s importer can preserve that ownership relationship by automatically setting the imported source as canonical. Medium also allows authors to set a canonical link manually in story settings.

The third is where engineering work becomes interesting. You cannot remove the provider boundary, but you can make everything before that boundary reproducible.

Do Not Automate the Wrong Layer

A brittle publishing bot often tries to automate this entire sequence:

research
→ draft
→ edit
→ format
→ authenticate to Medium
→ manipulate the editor
→ publish

The last three steps are where reliability drops sharply if you do not have supported API access.

A safer design moves the automation boundary earlier:

source
→ canonical article
→ validation
→ Medium derivative package
→ independent review
→ human/provider handoff
→ canonical verification
→ publication evidence

The difference looks small, but it changes the failure model completely.

If Medium changes its editor tomorrow, your canonical article is still intact. If import formatting breaks, you regenerate the derivative instead of rewriting the source. If the provider is unavailable, the package remains ready for a later attempt.

This is the same principle I use for AI workflows generally: the component producing an artifact should not be the only component deciding that the artifact is safe to ship. I explore that separation-of-duties pattern in Stop Letting AI Agents Approve Their Own Work.

Build the Canonical Article First

The most important design decision is deciding what owns the content.

For RayLabs, Medium is a distribution channel, not the source of truth. The canonical article lives on RayLabs first. A Medium version is a derivative generated from that approved article.

That gives the pipeline a stable contract:

canonical article
    ↓
content hash
    ↓
Medium package
    ↓
provider import

The package should never silently mutate the canonical article.

This gives you three useful properties.

Reproducibility. You can regenerate the Medium package from the same source.

Isolation. A Medium failure cannot corrupt or unpublish the canonical version.

Auditability. You can record exactly which article revision produced which external derivative.

This is more valuable than a clever publishing script because it protects the content when the external platform changes.

What the Automation Should Actually Produce

A useful Medium automation worker should not output “some Markdown.” It should output a publication package with enough evidence for a person to finish the provider-side step quickly and confidently.

A practical package can contain:

medium-package/
├── story.html
├── metadata.json
├── checklist.md
└── media/
    ├── hero.png
    ├── diagram-01.png
    └── diagram-02.png

story.html contains the Medium-adapted article. metadata.json records title, subtitle, canonical URL, tags, source revision, and content hash. media/ contains provider-compatible image assets. checklist.md describes exactly what the operator must verify after import.

The package is not merely convenient. It is a boundary object between automated infrastructure and a provider that still requires authenticated human interaction.

Medium Formatting Is Part of the Problem

One mistake is assuming that content that renders correctly on your own site will render identically inside Medium.

RayLabs tested that assumption and it failed.

A generated package that looked structurally correct before import produced several provider-side problems: images disappeared, a comparison table vanished, text diagrams became code editors, empty headings appeared, and blockquotes were malformed.

The important lesson was not “Medium is bad at HTML.” The lesson was that provider compatibility must be tested as its own output contract.

The derivative generator was changed to adapt content specifically for Medium:

• unsupported or fragile structures were flattened into semantic paragraphs or lists;
• diagrams that depended on precise layout were converted into image assets or structured lists;
• real quotes remained native blockquotes;
• actual code remained code instead of turning diagrams into code blocks;
• heading hierarchy was preserved deliberately;
• images were emitted as provider-friendly figures with captions.

This is information a generic Markdown-to-Medium script cannot infer safely from syntax alone. It needs an explicit adaptation policy.

Use Import a Story When You Have a Public Canonical URL

If the article is already live on your own website, Medium’s official importer is the cleanest supported handoff.

The workflow becomes:

publish canonical article
→ validate public URL
→ generate Medium package/checklist
→ open Import a story
→ paste canonical URL
→ inspect imported draft
→ repair provider-specific formatting if needed
→ verify canonical
→ publish or schedule

Medium documents that imported stories automatically receive a canonical link pointing to the original source. That makes the importer especially useful for a site-first publishing strategy.

Do not treat the automatic canonical as permission to skip verification. After publishing, inspect the story’s canonical setting or page source and confirm that it points to the intended RayLabs URL.

A distribution pipeline is not complete because a button returned success. It is complete when the external artifact has the right content, identity, and canonical relationship.

A Better Quality Gate Than “The Script Ran”

A publishing worker should fail before handoff if the package is incomplete.

For example:

PASS only if:
- canonical URL is present
- source revision/hash is recorded
- title and subtitle exist
- required media files exist
- no unsupported source-only components remain
- internal links are intentional
- external references are valid
- SEO metadata is complete
- editorial review has passed

Then the provider-side verification can use a second gate:

PASS only if:
- heading hierarchy rendered correctly
- images rendered correctly
- captions survived
- quotes and code are semantically correct
- no empty headings/blocks appeared
- canonical URL is correct
- public Medium URL is recorded

These are different gates because they prove different things.

The first proves that your automation produced a valid derivative. The second proves that Medium rendered and published that derivative correctly.

Design for Failure Instead of Pretending It Will Not Happen

A robust workflow should make each failure boring.

Failure	Correct behavior
Research or draft generation fails	Keep the last valid source; do not create a publishable derivative
Metadata validation fails	Stop before Medium handoff
Image conversion fails	Mark the package blocked; do not silently omit the visual
Medium import is unavailable	Keep the package and retry later
Medium formatting is broken	Repair the derivative, not the canonical article
Canonical is missing or wrong	Do not count the external publication as complete
Analyzing Technical Review Feedback For Multi Flavor Android model is unavailable	Fall back to deterministic checks and human review
Medium publication succeeds but evidence is missing	Keep channel state unverified until the URL/canonical is recorded

This is why I prefer explicit state transitions over a single published=true flag.

A real content pipeline may need states such as:

source_ready
→ draft_ready
→ quality_passed
→ canonical_published
→ derivative_ready
→ handoff_ready
→ external_published
→ external_verified

The state tells you what evidence actually exists.

Browser Automation Is Not Automatically an Upgrade

When an API disappears, browser automation is an obvious temptation. A Playwright script can sign in, navigate to the editor, paste content, upload images, and click Publish.

Technically possible does not mean operationally preferable.

Browser automation adds several new dependencies: authenticated session state, DOM selectors, editor behavior, anti-abuse controls, upload timing, and UI changes outside your control. It can be useful when the volume justifies that maintenance cost and the platform permits the workflow, but it should not be the default response to a missing supported API.

For a low-volume technical publication, automating the deterministic 90–95% and keeping a short human handoff can be cheaper and more reliable than maintaining a fragile pseudo-API built on browser clicks.

The optimization target is not zero clicks.

It is minimum unverified work.

The RayLabs Pattern

The RayLabs Medium pilot ended up with this boundary:

approved RayLabs article
→ deterministic Medium package
→ deterministic validation
→ bounded independent review
→ manual official Medium import
→ visual inspection
→ canonical verification
→ channel evidence

The architecture intentionally excludes unsupported Medium API publishing and autonomous browser publication.

That may sound less ambitious than “fully automated publishing,” but it gives the system a property I care about more: a provider failure cannot damage the canonical article.

During the pilot, a broken Medium import exposed real formatting incompatibilities while the live RayLabs article remained unchanged. That is exactly what the architecture was designed to achieve.

Practical Checklist

Before calling a Medium automation workflow production-ready, verify these questions:

• Is your canonical source explicit?
• Can the Medium derivative be regenerated deterministically?
• Does every derivative record the source revision or hash?
• Are images transformed into formats Medium reliably accepts?
• Have tables, diagrams, quotes, code, and headings been tested in the actual Medium editor?
• Does a failed import leave the canonical article untouched?
• Is the canonical URL verified after publication?
• Is the final Medium URL recorded as evidence?
• Can the workflow operate without pretending a new Medium API token is available?

If the answer is yes, you already have meaningful publishing automation,even if a human still performs the last provider-side action.

The Real Goal Is a Reliable Boundary

Medium’s current API limitation does not make content automation pointless. It makes architecture more important.

Automate research, drafting, metadata, formatting, image preparation, validation, packaging, and evidence collection. Keep the unsupported external boundary explicit. Use Medium’s official import path when a public canonical article exists. Verify what Medium actually rendered instead of trusting what your generator intended to render.

A good publishing pipeline does not need to pretend every platform has a programmable API.

It needs to know exactly where automation stops, what evidence exists at that boundary, and how the workflow recovers when the provider behaves differently than expected.