dev.to setup

dev.to is a syndication target: it hosts a copy of your article on dev.to, a domain you do not own. BirchSeek treats that differently from your own site.

The canonical rule

BirchSeek will not publish to dev.to until the article is live on your own site.

That is deliberate. A copy on dev.to with no canonical pointing home competes with your page in search, and dev.to’s domain authority means the copy frequently wins. You would be paying to outrank yourself. So the connector reads the article’s live URL, sends it as canonical_url, and refuses to run if there isn’t one yet.

In practice this means ordering your connectors: your own site first, dev.to second. If you schedule both for the same moment, the dev.to publish fails with a message telling you the article is not live yet. Schedule it a little later, or let the refresh run pick it up.

Turn cross-posting on

Connecting dev.to is not the same as asking for copies. Automatic cross-posting is off on every new project, and while it is off nothing is ever sent here. Switch it on under Settings → Project; it applies to every syndication connector on the project at once.

Turning it on asks you to accept one risk in writing, and it is a real one - see the Medium guide for what cannot be ruled out there. Turning it back off is never refused, for any reason.

Step 1 - get an API key

1. In dev.to, open Settings → Extensions.
2. Under DEV Community API Keys, name a key BirchSeek and generate it.
3. Copy it. dev.to shows it once.

The key grants full posting access to your account, so it is stored sealed with XChaCha20-Poly1305 like every other connector secret and is never returned by the API.

Step 2 - configure the connection

Setting	What it does
Publish immediately	Off by default: the post is created as a draft so you can look at it before it goes live.
Organization	Post under a dev.to organization your account belongs to, rather than your personal profile.
Series	Groups related posts into a dev.to series.

Tags are taken from the article and normalised to dev.to’s rules automatically: lowercase, alphanumeric only, at most four. dev.to rejects hyphens and spaces in tags, so ai-seo becomes aiseo rather than failing the publish.

What gets sent

The article body goes over as markdown, which is what the pipeline produces anyway, so nothing is converted or re-rendered on the way. Along with it: the title, the meta description as the post description, your tags, and the canonical URL.

The copy ends with a ## Sources block, the same one your own site’s article carries: each verified claim paired with the page it was checked against. The project setting that can switch that block off for your own site does not reach this copy, and deliberately so - dev.to’s API has no citation field, so the body is the only place the evidence can travel. The canonical link back to your page goes with it. (Off-domain placements are a different feature and build their own Sources block; see placements.)

Troubleshooting

• “article must be live on your own site first” - the article has no live URL yet. Publish to your primary connector, or set the live URL on the article, then retry.
• 401 - the API key was revoked or mistyped. Generate a new one in Settings → Extensions.
• 429 - dev.to rate-limits article creation. BirchSeek honours the Retry-After it sends and retries automatically; no action needed.
• Duplicate posts - BirchSeek matches your existing dev.to articles on canonical URL before creating, so a retry updates the existing post rather than adding a second one.