Docs and Changelog API

Scripts and CI jobs can do most of what the Docs and Changelog consoles do: create and configure sites, write and publish pages and entries, upload files, manage domains, read analytics and the activity log. A full API reference for these two products is not published yet. The endpoints on this page are stable and work with an API key today; this page lists them by task, with the scope each one needs.

Paths below are relative to https://evohub.io. Requests need an API key, sent as described in API overview. Answers use the same envelope as the rest of the API: {"data": ...} on success and an error object on failure. See Errors.

#Scopes

Each endpoint needs one scope. Give a key only the ones its job needs.

The activity log of a site, and of the organization, is read with the site read scope.

A key without the scope gets 403 FORBIDDEN, never 401. A key sees organization-wide sites and, for a personal key, your teams' sites; an organization key scoped to a team sees that team's. A site it cannot see answers 404, the same as one that does not exist. See API keys and scopes.

#Docs

#Sites

#Versions and languages

#Sections and pages

#Publishing

On a site that requires review, publishing goes through change requests and these answer 409 REVIEW_REQUIRED. Open a change request instead (below); a person approves and merges it.

#Revisions

#Change requests

#Snippets and API references

#Files and redirects

#Import and GitHub

Connecting a site to GitHub in the first place is done by a person in the console. See GitHub sync and Import and export.

#Domain and access

See Custom domain and Private docs.

#Analytics, feedback and link health

#Activity log

#Changelog

#Sites

#Categories

#Entries

#Publishing

On a changelog that requires review, publishing and scheduling need the approvals first and otherwise answer 409 REVIEW_REQUIRED. A key can submit an entry; a person approves it. See Writing entries.

#Revisions and images

#Subscribers

#Slack and webhooks

See Reaching readers.

#GitHub

Connecting a changelog to GitHub in the first place is done by a person in the console. See GitHub.

#Domain and access

#Analytics and feedback

#Activity log

#Create and publish a changelog entry

A release pipeline can write the entry and publish it in two calls. The key needs changelog:entry:write and changelog:entry:publish.

# 1. Create the entry (a draft)
curl https://evohub.io/api/v1/changelog/sites/$SITE_ID/entries \
  -H "Authorization: Bearer $EVOHUB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Faster exports",
    "summary": "CSV exports now finish in seconds.",
    "body_md": "Exports of large projects used to take minutes. They now stream as they are built.",
    "version": "2.4.0",
    "category_ids": ["'"$CATEGORY_ID"'"],
    "tags": ["exports"]
  }'

# 2. Publish it, and tell subscribers and integrations
curl -X POST https://evohub.io/api/v1/changelog/entries/$ENTRY_ID/publish \
  -H "Authorization: Bearer $EVOHUB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"notify": true}'

title is required; a blank slug is made from the title. The answer to the first call is the entry, with its id. notify is optional; leave it out to keep the entry's setting. To publish later instead, call /schedule with {"publish_at": "2026-12-01T09:00:00Z"}. Entry fields also include cover_image_url, pinned, author_name and date.

#Update and publish a docs page

# 1. Edit the draft; only the fields you send change
curl -X PATCH https://evohub.io/api/v1/docs/pages/$PAGE_ID \
  -H "Authorization: Bearer $EVOHUB_API_KEY" \
  -H "Content-Type: application/json" \
  -H 'If-Match: "7"' \
  -d '{"title": "Install the CLI", "body_md": "Run `brew install acme` and sign in."}'

# 2. Publish the draft
curl -X POST https://evohub.io/api/v1/docs/pages/$PAGE_ID/publish \
  -H "Authorization: Bearer $EVOHUB_API_KEY"

Every save answers with an ETag holding the page's version. Send it back as If-Match (or as version in the body) and a save made over someone else's newer edit is refused with 409 EDIT_CONFLICT, carrying the page as it now stands; leave both out to overwrite. A page's section is changed with PUT /api/v1/docs/sites/{siteID}/order, not on the page. To create a page, POST /api/v1/docs/sites/{siteID}/pages with title, and optionally slug, body_md and section_id; ?version= picks the docs version, and the default version is used without it.

On a site that requires review, step 2 answers 409 REVIEW_REQUIRED: open a change request for the page with POST /api/v1/docs/sites/{siteID}/change-requests and a title, and a person approves and merges it.

#What is not part of the API

• Reserved for a person. Approving, requesting changes on, merging and reverting docs change requests and approving changelog entries; connecting a docs site or a changelog to GitHub; and issuing private docs credentials (a new reader-token signing secret, a test token, a read token) are done by a person in the console. A key gets 403 PERSON_REQUIRED. See What a key can never do.
• Public-site routes. The addresses under /api/v1/docs/public/ and /api/v1/changelog/public/ serve your published sites to their visitors. They are not part of the API, may change without notice, and do not take an API key.
• Console-only helpers such as the console home, notifications and who-is-editing indicators are left out here.

#Related

• API overview
• API keys and scopes
• Errors
• Docs overview
• Review and change requests
• Changelog overview