Gixo API

Try all nine module integrations in the Gixo for Platforms playground, with free deterministic fixtures, downloadable code examples and a Postman collection.

Start, poll, list and export Gixo work from your own systems: Quill articles, Lumen presentations, Arc proposals, Business documents, Lex drafts and Prism visuals. Every call runs as your Gixo account, through the same paths the app uses, so your plan, team workspace and access rules apply exactly as they do in Gixo.

OpenAPI 3 document (import it into Postman, Zapier, Make, n8n, Power Automate or Salesforce External Services): /api/v1/openapi.json

Keys and scopes

API access comes with a Gixo Enterprise plan. Create a key under Settings > Integrations and copy it when it is shown: Gixo stores only a hash of it. Send it on every request:

Authorization: Bearer gixo_live_<prefix>_<secret>

A key holds the scopes you pick when you create it, and reaches nothing else. {product}:read covers GET (status, list, fetch, export); {product}:write covers POST (start work) and includes read. A key works across products, but each call still needs that product's plan on the account: starting work in Lumen needs a Lumen plan.

No scope reaches billing, team management, publishing connections or administration. GET /api/v1/account works with any key and reports its scopes and, per product, whether your plan can start new work now.

The flow

Every product has the same shape. Generation is asynchronous:

1. POST /api/v1/{product}/{collection} starts the work and answers 202 Accepted with the artifact's id and statusUrl, also sent as the Location header. (Prism renders immediately and answers 201 Created with the saved visual.)
2. GET the status URL every few seconds until status is succeeded or failed. It reports queued, processing, progressPercent and stage on the way.
3. Download it from one of the links in exports, for example GET /api/v1/lumen/presentations/{id}/export/pptx. Add ?body=markdown or ?body=html to the status URL to receive a text artifact inline.

An artifact also reports reviewStatus: what Gixo's automated source review found when it checked the artifact's claims against its sources. succeeded says the artifact was generated; reviewStatus says whether to check it before relying on it.

• reviewed: a review covered the artifact and found nothing to check.
• needs-review: the review found claims a person should check. Open the artifact in Gixo (appUrl) to see them.
• not-reviewed: no complete review covers the artifact as it stands. The review did not run or could not finish, the artifact is still generating, or it was edited after the review.
• not-applicable: there is nothing to review. The generation failed, or the product generates no claims of its own (Prism visuals are drawn from your data).

Only reviewed means a review passed. The same field appears in the MCP tools that read a saved Quill draft, an Arc proposal or a Lex document.

curl -X POST https://gixo.ai/api/v1/lumen/presentations \
  -H "Authorization: Bearer $GIXO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: q3-board-review-2026" \
  -d '{"brief":"Q3 board update: revenue vs plan, churn, hiring, and the two decisions we need.","purpose":"board","slideCount":14}'

curl https://gixo.ai/api/v1/lumen/presentations/$ID \
  -H "Authorization: Bearer $GIXO_API_KEY"

curl -o deck.pptx https://gixo.ai/api/v1/lumen/presentations/$ID/export/pptx \
  -H "Authorization: Bearer $GIXO_API_KEY"

Products

Each collection also lists your artifacts: GET /api/v1/{product}/{collection}?offset=0&limit=20, newest first, with nextOffset for the next page.

What the API does not do

• Lex drafts only. The API never approves a legal document, delivers it or sends it for signature: a person reviews every Lex draft in Gixo.
• Arc drafts stay in Gixo. The API never sends a proposal to a buyer.
• The Business API produces Business documents. An instruction that would make a deck, proposal or visual is refused with the path of that product's API.
• Stanza stories and Folio books are not part of v1.

Retries and idempotency

Send an Idempotency-Key header (up to 255 printable characters) on every POST. Retrying with the same key and the same body returns the first answer, with the same artifact id, instead of starting and paying for a second generation; the replay carries Idempotent-Replayed: true. The same key with a different body is refused with 422 IDEMPOTENCY_KEY_REUSED. Keys are remembered for 24 hours per account and product. A refused request (plan, validation) is not remembered, so you can retry it with the same key once the cause is fixed.

Errors

Every refusal has the same shape:

{ "error": "InvalidRequest", "message": "'deck' is not a deck purpose.", "code": "INVALID_REQUEST", "validValues": ["general", "pitch", "board", "sales", "training"] }

Keys made before scopes

Keys created before scoped keys were introduced carry no scopes and keep the full access they were issued with. GET /api/v1/account reports them as fullAccess: true. Create a scoped key, move your integration to it, and revoke the old one.