How Vrite Integrates With Existing Sites and Workflows

Updated

Vrite connects to an existing site through three separate paths: a headless API that any front-end can call, bi-directional Git sync for a docs-as-code workflow, and a JavaScript SDK for popular frameworks. You can use one or all three. The right choice depends on whether your content lives in a repository, in a CMS, or both.

Headless API: content in Vrite, rendering anywhere

Vrite is headless, meaning content is created and managed in Vrite but published through your own front-end. The API is the integration point: your site requests content from Vrite and renders it with your own components, routing, and styling.

This fits when you want editorial tooling (the WYSIWYG editor, metadata, variants, permissions) without adopting Vrite's presentation layer. A typical flow:

  1. Authors write and manage content in the Vrite dashboard.
  2. Your build or server calls the Vrite API to fetch published content.
  3. Your front-end renders it, mapping Vrite's structured content (including XML-like custom elements) to your own components.

The expected result is a site that looks and behaves like your existing product, with content operations handled in Vrite. The main thing to plan for is the mapping step: custom elements in Vrite content need a corresponding renderer on your side, or they will not display as intended.

Git sync: docs-as-code without giving up the editor

Vrite offers bi-directional Git sync, described as a way to "utilize docs-as-code approach" and onboard quickly. Bi-directional means changes flow both ways: edits made in Vrite reach your repository, and changes committed to the repository reach Vrite.

This suits teams that already review documentation through pull requests and want to keep that process while giving writers a visual editor. Practical points to verify before committing:

  • Conflict handling. With two-way sync, the same file can change in both places. Confirm how Vrite resolves or surfaces conflicts before you rely on it for a busy repository.
  • File format and structure. Check how Vrite content maps to files in the repo, since that mapping determines whether your existing build pipeline picks the files up unchanged.
  • Scope. Decide which content syncs and which stays Vrite-only, so generated files don't collide with hand-maintained ones.

A concrete scenario: a team keeps its docs in a Git repo reviewed by engineers, but writers prefer Vrite's editor. With sync enabled, writers edit in Vrite, engineers review the resulting commits, and the existing static-site build runs as before.

JavaScript SDK: framework integration and extensions

The JavaScript SDK is the supported way to integrate Vrite with popular frameworks and to extend Vrite's functionality. Use it when the raw API calls would otherwise mean writing your own client: fetching content, handling authentication, and wiring responses into a framework's data layer.

The SDK also underpins the extension system, which is where workflow automation lives. Extensions can customize content, automate workflows, and connect Vrite to other tools. If your integration need is "when content changes, do X in another system," an extension is usually a better fit than polling the API from your site.

Choosing between the paths

Your situation Best fit Why
Existing front-end, want Vrite only for authoring Headless API (or SDK) Content is fetched at build or request time; presentation stays yours
Docs already in Git, reviewed via PRs Git sync Keeps repository workflow while adding a visual editor
Need to trigger actions in other tools Extension system via SDK Automates workflows inside Vrite rather than around it
Using a mainstream JS framework JavaScript SDK Less client code than calling the API directly

These paths combine. A common setup is Git sync for the docs repository plus the API for a marketing site that pulls selected content, with an extension handling notifications.

What to check before you start

  • Self-hosting vs. cloud. Vrite is open-source and can be self-hosted, or you can use the cloud offering. The page states self-hosting avoids lock-in; it does not state pricing or login terms, so confirm those directly on the pricing page if cost matters.
  • Content model fit. Vrite's editor supports first-class code editing, Markdown, keyboard shortcuts, IDE-level syntax highlighting and autocompletion, and XML-like custom elements. If your site renders code blocks or custom components in a specific way, plan the mapping early.
  • Metadata and variants. Metadata (assigned members, tags, deadlines, custom JSON) and content variants for internationalization and A/B testing are stored alongside content. If your front-end needs these, confirm they are exposed through the API before designing around them.
  • Search. Vrite includes AI-powered semantic search and Q&A over your content, and the API lets you offer the same experience to your users. Treat this as an optional layer, not a requirement for integration.

The fastest way to validate a plan is a small pilot: sync one documentation section or fetch one page through the API, render it in your existing site, and confirm the output matches what your current pipeline produces.