A publishing adapter should respect the editor's working environment. For Ghost, that means thinking beyond the title and body of an article. Imported content needs to remain reviewable, retain its structure, and arrive with sensible authorship and tagging. A technically accepted request is only the beginning of that check.
This guide describes a small editorial workflow for a Ghost publication you manage. It focuses on draft preparation, conversion review, and a clear handoff to the publisher. WriteAPI.com is an independent educational resource, not the operator of a Ghost service. The goal is to help you ask the right implementation questions before connecting an automated source to a real publication.
Decide what the integration owns
Start by drawing a boundary between the source system and the Ghost editor. Your source might own the brief, approved references, and initial draft. Ghost might own the final layout and publication decision. Without an explicit boundary, a later synchronization can overwrite work that an editor has already improved.
Choose a rule for edits after the first import. A simple pilot can stop synchronizing the body once a person begins editing it in Ghost. A more elaborate system can compare versions and ask for approval before replacing content. The right choice depends on your workflow, but silent overwrites should not be the default.
Record the imported version
Keep your internal article identifier separate from the destination post identifier. Save the relationship after creation. Include a short record of the source version that was imported so someone investigating a mismatch can identify which draft actually arrived. This is more reliable than matching records by title alone.
Choose a supported content representation
The Ghost post-creation documentation describes creating posts through the Admin API, including Lexical content and an HTML-source option. It notes that converting HTML to Lexical can be lossy: the rendered result may differ from the supplied HTML. That warning belongs directly in your testing plan rather than being treated as an obscure implementation footnote.
Select a representation based on what your editorial source can produce reliably. Do not generate a complicated document structure merely because the destination supports it. A small set of well-formed paragraphs, headings, lists, and links is easier to validate than arbitrary markup assembled from several incompatible sources.
Keep a copy of the preconversion material. When a reviewer notices a difference, compare the source, submitted payload, and rendered output. That sequence helps identify whether the issue began in the draft, the adapter, or the destination's interpretation. It also prevents unnecessary changes to a prompt when the actual defect is formatting.
Create a conversion fixture
Before importing complete articles, create one test document with the structures your publication uses. Include a paragraph, a subheading, an ordered list, an inline link, an image reference, and any special block that matters to your editorial format. Keep the fixture short enough that a person can inspect it completely.
Give each element a clear purpose. A long heading tests wrapping. A sentence containing non-English characters tests preservation. A short code sample tests whether characters are displayed as code instead of interpreted as markup. These are suggested checks for your implementation, not promises that every configuration will behave the same way.
Preview the fixture in the actual theme. The editor representation and public page can differ in ways that matter to readers. Check narrow layouts and unusually long content. When a conversion loses information, decide whether to simplify the source format, adjust the adapter, or require a manual editorial correction.
Keep drafts separate from publication
For the first integration, make draft creation the only successful endpoint of automation. An editor should inspect the imported result before it becomes public. This keeps the initial failure modes manageable and makes it easier to learn how source content behaves in your publication.
Treat scheduling and sending as separate editorial decisions when they are part of your setup. A draft arriving in a CMS is not automatically permission to distribute it elsewhere. Write those boundaries into the handoff so the person operating the integration knows which actions have and have not been approved.
Avoid a vague status called done if it hides several different outcomes. Imported, reviewed, approved, and published answer different questions. Your internal record can use those labels even when the destination uses its own specific states. Map between the two deliberately rather than pretending they are identical.
Resolve authors and tags intentionally
Authorship should reflect the publication's actual attribution decisions. Do not let an automated import invent a person, a credential, or an editorial role. Establish how the integration selects an existing author and what it does when the intended attribution is unavailable. An explicit review task is preferable to a misleading public byline.
Use a controlled tag mapping for the pilot. Decide which tags organize reader-facing archives and which, if any, are internal to the publication. Prevent small spelling variations from creating an untidy collection of near-duplicate topics. The tagging policy belongs to the publication; the adapter's job is to apply it consistently.
Inspect the resulting archive pages after importing a test post. A tag can look correct in a payload while still making little sense to a reader. Ask whether the article is discoverable under the expected topic and whether the archive description explains what the collection is for.
Make updates conservative
An update should identify both the destination record and the source version being applied. Before changing a draft, determine whether a person has edited it since the last import. Your implementation can detect or surface that conflict according to the capabilities of your integration, but it should not assume that every difference is safe to overwrite.
Choose a conflict policy that an editor can understand. For example, stop the update and show both versions when the destination has changed. In a small workflow, a manual merge may be entirely reasonable. Reliability does not require eliminating every human step; it requires making the necessary steps visible.
Test uncertain outcomes as well. If the connection fails after a creation request, inspect whether the post exists before trying again. Save enough operation context to distinguish a genuinely new article from a retry. Duplicated drafts waste time and make it harder to identify the version that should be reviewed.
Review the publication as a reader
Read the preview from beginning to end. Check that the opening establishes the question, that headings follow a coherent hierarchy, and that links describe their destination. Verify image alternatives and captions separately from the body. An import should preserve the reader's experience, not only the approximate shape of the original text.
Review the excerpt and title together. They should introduce the same article rather than promising two different things. Check the slug for clarity and stability. A title change during editing does not necessarily justify moving a URL that readers may already know, so make URL changes an explicit decision.
The Ghost CMS Write API guide provides a focused implementation checklist. For broader comparisons between destination adapters, use the CMS Write API overview. Keep the comparison grounded in your actual editorial needs rather than assuming every CMS should behave like the system you used before.
Maintain a small release checklist
Write a checklist that fits on one screen: correct destination, correct source version, conversion reviewed, attribution checked, tags checked, media reviewed, and publication approved. Add a named owner for any unresolved task. A checklist helps most when the items correspond to concrete decisions rather than generic encouragement to be careful.
Store test results when you change the adapter or publication theme. Re-run the conversion fixture and compare the rendered page. Keep a note explaining intentional differences so a future maintainer does not spend time fixing a change that an editor actually requested.
Conclusion: preserve the editorial handoff
A useful Ghost integration makes the imported draft easy to inspect and safe to continue editing. It preserves identifiers, treats conversion as a testable step, and avoids confusing draft creation with permission to publish. It also respects the editor's changes instead of silently replacing them.
Begin with one conversion fixture and a draft-only workflow. Resolve ownership, attribution, and conflict handling before increasing volume. Once those boundaries are clear, the integration becomes a dependable bridge between source material and a publication, rather than a second editor with unexplained authority.
