Give your pipeline a deploy token and it can publish a built folder to arcdoq with no browser and nobody signed in. Point Claude at this page and it will write the workflow for you. The one step that stays yours is pasting the token into your repository secrets.
Skip this page. arcdoq-docsite turns a folder of markdown into a finished site and publishes it in the same step, so there is no request to write and no token to pass by hand. The rest of this page is the raw endpoint underneath it, for everything else.
- uses: actions/checkout@v4
- uses: nimbarc/arcdoq-docsite@v0.9.1
with:
corpus: .
site: docs
visibility: private
arcdoq-token: ${{ secrets.ARCDOQ_DEPLOY_TOKEN }}In the app, open Tokens and choose New token. Name it after the thing that will use it, so a list of them stays readable later. You need to be an admin or owner of the workspace.
On GitHub: Settings, Secrets and variables, Actions, New repository secret. Name it ARCDOQ_DEPLOY_TOKEN. Any CI with a secret store works the same way.
ARCDOQ_DEPLOY_TOKEN=arcdoq_deploy_<id>_<secret>Tokens start with arcdoq_deploy_ on purpose: the prefix is distinctive enough for a secret scanner to catch if one ever lands in a commit. If that happens, revoke it in the app. Rotating is cheap; a live credential in git history is not.
A deploy is one request: your built folder as a list of files. Rather than copying a script you have to understand, give Claude this page and the two facts it cannot guess, your slug and your build directory. It writes the workflow, and stops at the secret, which is yours to paste.
Read https://arcdoq.com/docs/deploy and set up arcdoq deploys for this repo.
The site slug is "docs", my built output is in ./dist, and the site should be
private.
Do not put the token in any file. Tell me to add ARCDOQ_DEPLOY_TOKEN to the
repository secrets myself.Writing it by hand instead? Everything the workflow needs is below. Build, walk the output directory, and send one request.
Text files go as utf8. Anything binary, an image or a font, goes as base64 with encoding set. Paths are relative to your build directory, and a root index.html is required.
The first deploy to a new slug must say visibility, and arcdoq will not guess. A site published from CI has nobody watching it, and the two wrong guesses are not equally bad: wrongly private is noticed in seconds, wrongly public may never be. Later deploys leave it out and inherit whatever the site already is.
public and private are the only two a deploy may set. A passcode site is made in the app, because a passcode is a shared secret and a workflow file is not where one belongs. Create the site private from CI and set the passcode afterwards; later deploys inherit it.
One thing that fails quietly: a documentation corpus built with "walk": true cannot record a walk on a public site. That page is served with no cookie at all, so the write would be open to the internet and arcdoq refuses it. The buttons still render and every one of them is turned away. Deploy it private, or give it a passcode.
Authorization: Bearer $ARCDOQ_DEPLOY_TOKEN
Content-Type: application/json
{
"site": "docs",
"visibility": "private", // required on the FIRST deploy only
"files": [
{ "path": "index.html", "content": "<!doctype html>..." },
{ "path": "assets/app.css", "content": "body{...}" },
{ "path": "assets/logo.png", "content": "iVBORw0KGgo...", "encoding": "base64" }
]
}{
"success": true,
"created": false,
"slug": "docs",
"visibility": "private",
"url": "https://acme.sites.arcdoq.com/docs",
"serving": "live",
"message": "Published 43 files to docs."
}POST https://mcp.arcdoq.com/deploy with a bearer token. The site is keyed by slug, not by an id, so the same three lines of config resolve to the same site forever and your pipeline keeps no state. If the slug does not exist yet, the deploy creates it.
Still stuck? Email support@arcdoq.com.