Developer Workflows

The web editor is the simplest place to learn ZyVOP. Developer workflows become useful when your articles already live in files, a repository, a CMS, or an automated system.

Choose the right toolCopy Anchor Link

Start with the CLICopy Anchor Link

The CLI provides the clearest bridge between a Markdown file and ZyVOP:

npx zyvop login
npx zyvop publish ./posts/my-article.md --dry-run
npx zyvop publish ./posts/my-article.md

Use --dry-run before the first real publish to inspect validation and destination choices without sending the article.

See CLI Overview, Configuration, and zyvop publish.

Keep publishing metadata with the articleCopy Anchor Link

YAML frontmatter can describe the title, excerpt, tags, canonical URL, cover image, publication state, AI disclosure, and selected destinations. Keeping this metadata in the file makes changes reviewable in Git.

---
title: "How I Diagnosed a Slow Query"
tags: [postgres, performance, debugging]
canonical_url: https://example.com/posts/slow-query
cross_post:
  devto: true
  hashnode: false
ai_disclosure: human_written
---

Use only documented fields from the Frontmatter Reference.

Automate carefullyCopy Anchor Link

Before enabling automatic publication from a repository:

1. make a dry run part of pull-request validation;
2. store tokens in repository or CI secrets;
3. publish only intended files and branches;
4. use stable identifiers so updates match the correct article;
5. review canonical and destination settings in code review; and
6. test with one article before enabling a large content directory.

The GitHub Actions guide includes validation and publication examples.

Use the REST API for application workflowsCopy Anchor Link

The REST API is appropriate when publishing is initiated by a CMS, internal tool, or backend service. Authenticate with a ZyVOP developer token and handle validation and provider failures explicitly.

Start with REST API Overview & Authentication, then use the Publish Article reference and API errors.

Use MCP with clear intentCopy Anchor Link

MCP lets compatible clients perform supported ZyVOP operations through structured tools. Begin with read-only requests, such as listing posts or checking analytics, before allowing content changes.

When asking an agent to create content, specify whether the result should be a draft, scheduled post, or published article. Explicitly name distribution destinations and review the returned content before publication.

Understand authentication choicesCopy Anchor Link

• Browser sessions authenticate the web application.
• Developer tokens authenticate the CLI, API, GitHub workflows, and MCP tools.
• Provider credentials authorize delivery to external destinations.

These credentials serve different purposes. Do not substitute one for another or expose them in frontmatter, logs, prompts, or committed workflow files.

A sensible progressionCopy Anchor Link

1. Publish one draft through the web editor.
2. Publish one local file with a CLI dry run.
3. Add frontmatter and stable identifiers.
4. Add CI validation without automatic publication.
5. Enable publication only after the reviewed workflow behaves predictably.
6. Add external destinations one at a time.