How to build a checked content workflow with the Claude API

A source link can be real while the sentence beside it is wrong. Your first Claude API content workflow should make that mismatch easy to catch before anything reaches your website.

For a small SaaS business, start with a tutorial about a feature you shipped. Give Claude your product notes and supporting sources. Ask for a draft and a separate list showing what supports each factual claim. Keep the publish button under your control.

What is the Claude API?

The Claude API lets your software send messages to Claude models and collect their replies. You can use it to turn product notes and source material into drafts without copying everything into a chat window.

According to the API overview, the service offers a Messages API for sending messages, plus separate APIs for batch requests, counting tokens, listing models, and handling files. You don't need to build around all of them to get started.

For a first content workflow, use the Messages API. Your application supplies the instructions and evidence, then receives Claude's response. Your code decides what happens next.

That last part matters. Receiving a draft doesn't require publishing it. You can save the response for review, reject it, or send it through another check. Treat those as separate steps rather than one action called “generate content.”

A useful first workflow has a narrow job:

1. Read notes about one shipped feature.
2. Send those notes and supporting sources to Claude.
3. Request a tutorial and a list of its factual claims.
4. Save both for your review.
5. Publish only after you approve the draft.

You don't need a chatbot interface for any of this. A script that reads a file and saves a draft is enough to test the idea.

Build the claim checker before you connect the publisher. That means deciding what evidence a draft must carry, where you'll inspect it, and what happens when evidence is missing. The first useful result is a draft you can check without reconstructing where every sentence came from.

How do you make your first Claude API request?

Create a Claude Console account, create an API key, and install an SDK. The getting-started guide documents those steps and the ANTHROPIC_API_KEY environment variable.

For a Python project, the basic setup is:

python3 -m venv .venv
source .venv/bin/activate
pip install anthropic
export ANTHROPIC_API_KEY="your-api-key-here"

Keep the key outside your article files and source packs. Your content workflow needs access to the credential, but your drafts don't.

The API usage primer shows the Python call through client.messages.create. The following example adapts that pattern to a content task. Create feature-notes.txt and sources.txt with your own material before running it.

from pathlib import Path
import anthropic

notes = Path("feature-notes.txt").read_text()
sources = Path("sources.txt").read_text()

client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{
        "role": "user",
        "content": f"""
Write one tutorial using only the supplied evidence.
Return two sections: DRAFT and CLAIMS.
For each factual claim, include its source ID,
supporting passage, and anything that needs checking.
Omit unsupported claims from the draft.

PRODUCT NOTES:
{notes}

SOURCES:
{sources}
"""
    }],
)

for block in message.content:
    if block.type == "text":
        print(block.text)

Run this manually before wiring it into anything else. Read the output alongside the files you supplied. Check whether Claude followed the requested format and whether it left out facts you couldn't support.

Printing the response is enough for the first test. Add storage, retries, and stricter output checks once you know what a useful response looks like. Otherwise, you're building machinery around a draft you haven't judged yet.

Send the evidence with every drafting request

The standard Messages API is stateless: you send the conversation history needed for each request. The API usage primer states this explicitly.

For your content workflow, assume each drafting request needs its own evidence. Don't rely on a previous run having introduced your product, explained its limits, or established which sources you trust.

Build a small source pack for one article. For a tutorial about a shipped feature, include:

• Product notes describing what the feature does today.
• The steps a reader must follow to use it.
• Known limits, prerequisites, and plan restrictions.
• External passages needed to explain any outside tools.
• Source IDs and URLs for material you may cite.

Keep product facts separate from writing instructions. “The feature requires an existing account” belongs in the evidence. “Use short paragraphs” belongs in the prompt. Separating them makes the pack easier to inspect and reuse.

Give each source a simple ID, such as product-notes or api-guide. Include the relevant passage beside it. If a source has a publication date or product version, preserve that information too.

A URL alone isn't enough for this starter workflow. Supply the text you want Claude to use rather than assuming it has read the linked page.

Choose the article's scope before sending the request. “Explain how to configure the feature” gives you a draft you can test against the product. “Write the complete guide to this category” asks for claims your source pack may not cover.

Keep the first task small enough that you can personally check every instruction and factual sentence. Expand only after the checks work.

Request a draft and a claim list together

The Messages API accepts your instructions as message content, so you can ask Claude for both prose and supporting evidence in one request. The API usage primer demonstrates that basic request structure.

Ask for two clearly separated outputs. The draft is what you might publish. The claim list is what you use to review it.

For each factual claim, request:

• The exact sentence from the draft.
• The source ID that supports it.
• The supporting passage from that source.
• Any uncertainty or missing evidence.

Make the prompt explicit about what counts as a factual claim. Include setup requirements, feature availability, comparisons, and performance statements. Don't let the check focus only on sentences containing numbers.

A useful instruction is: “If the supplied evidence doesn't support a claim, leave it out of the draft and list it separately as a question.” That gives you a place to find missing facts without putting guesses into publishable prose.

Don't confuse a requested format with a guaranteed result. Your script should still check that both outputs exist. If you later request JSON, check that it parses and contains the fields your review screen needs.

The claim list is a review aid, not a certificate of truth. Claude choosing a passage doesn't prove the passage supports its sentence. The list simply puts the proposed evidence beside the claim so you can judge the connection.

Keep that distinction visible in your interface. Label the draft “needs review,” not “verified,” when the model returns successfully. A completed API call tells you the request produced a response. Your approval should mean something stricter.

Check whether the passage supports the whole sentence

Anthropic's batch API processes Messages requests asynchronously and offers a 50% cost reduction, according to the API overview. That supports a claim about batch request costs. It doesn't establish that your entire content operation will cost half as much.

That difference is exactly what your review must catch. A citation can point to the right page while the draft stretches what the page says.

Read the claim and its cited passage side by side. Check three things:

1. Does the passage support every part of the sentence?
2. Did the draft preserve the source's conditions and limits?
3. Did it turn a possibility into a promise?

Comparisons deserve extra attention. If your notes describe your own export feature, they don't automatically support “easier than competing tools.” You need evidence for the comparison, not just evidence that your feature exists.

Treat performance numbers the same way. If your own test supports a result, keep the test conditions attached. If your source pack has no measured result, remove the number rather than asking Claude to make the sentence sound more convincing.

You can add another model call to propose corrections or flag unsupported wording. Keep that output in the review queue too. Asking the same system to reconsider a sentence doesn't turn its answer into independent proof.

The strongest manual check depends on the claim. Read the cited passage for an external fact. Inspect the product for a feature claim. Follow the steps for a tutorial.

If a sentence remains hard to verify, narrow it until the evidence supports it. Clear, limited claims are more useful than impressive sentences you can't defend.

Keep publishing behind your approval

A Messages API response contains generated content, a stop reason, and token usage, as shown in the API usage primer. It doesn't tell you that an article's claims passed your checks.

Make approval a separate action in your software. Save the draft and claim list together, then let your publishing step accept only drafts you've approved.

For the first version, a folder or a simple review screen is enough. You need to see the draft, inspect its evidence, and record your decision. You don't need an elaborate dashboard to do that.

Use a small set of explicit states:

• Drafted: Claude returned content.
• Needs changes: a check found a problem.
• Approved: you reviewed the current version.
• Published: the approved version went live.

If the draft changes after approval, require another review. Otherwise, the version you publish may differ from the one you checked.

Start with one format, such as a tutorial for a shipped feature. Run the instructions yourself. Confirm that the labels match the interface and that the stated prerequisites are correct. Those checks give you concrete reasons to approve or reject the piece.

Keep a brief record of corrections. Write “invented a plan limit” or “compared speed without evidence,” rather than “bad output.” Use those notes to improve the source pack and prompt.

Don't remove the approval step just because several drafts looked fine. First decide which mistakes your checks can catch reliably and which still need your judgment. Automate the steps you've tested, while keeping uncertain claims away from the publish button.

How do you control Claude API costs?

Use the Message Batches API for work that can wait. The API overview documents asynchronous processing with a 50% cost reduction, and the Claude Platform page also advertises the batch saving.

For a content workflow, that makes batch processing worth considering for drafts you plan to review later. Use a normal Messages request when you're actively testing a prompt and need the response before taking your next step.

Keep the saving in perspective. Batch processing changes the request cost. It doesn't check the article, fix your source material, or perform your editorial review.

The API also offers a Token Counting API to count tokens before sending a message. Use it to inspect the size of your requests rather than guessing how much evidence you've packed into them.

Start cost control with a few clear choices:

• Include passages relevant to the article instead of unrelated documents.
• Keep the first draft's scope narrow.
• Record token usage alongside each saved response.
• Compare models using the same source pack and review rules.

The Models API lists available Claude models and their details. Use that list when choosing what to test, rather than treating an old model name in your code as a permanent choice.

Judge a model by the drafts you can approve, not just the price of a response. Record what you had to fix so you can compare the work each option leaves you.

Before scheduling a batch, finish one tutorial end to end: supply the evidence, generate the draft and claim list, check every claim, and approve the exact version you'll publish. Then automate that tested path. Leave publishing blocked whenever the evidence or your approval is missing.