Skip to content
Resource library
GOCUX / Documentation

Build with a clear contract.

Start with a workflow. Learn its inputs, permissions, outputs and failure states before connecting it to the rest of your system.

How this documentation is organised

Each guide describes one workflow or one endpoint: what it accepts, what permission it needs, what it returns, and how it fails. Where the topic exists in another service but has no GoCux equivalent, the guide says so and describes the supported migration instead of implying a route that is not there.

Families

Each family below opens at a page worth reading first. The catalog underneath filters by section, so the rest of a family is one control away.

  • Getting started — choosing a workflow, and the vocabulary the rest of the documentation uses.
  • Task API — durable work that someone approves before it runs, and the evidence it leaves behind.
  • Search — querying project knowledge and reading the passage a result came from.
  • Extract — turning supplied material into fields you can inspect.
  • FindAll API — building a candidate set against explicit criteria, with a verification step per match.
  • Monitor API — Pulse monitors, their runs, and how a completed run with no change differs from a failure.
  • Responses and chat — direct conversational requests and the supported chat-completions interface.
  • Service API — application connections and the migration guides that go with them.
  • Integrations and data integrations — reading account context, and using an external store as project evidence.
  • API reference — request and response shapes, headers, error objects and rate limits.
  • Resources — contract changes, versioning and the notes that outlive a single release.

Reading a guide

  1. Read the permission boundary before the example. A request shape does not tell you whether your workspace is entitled to send it.
  2. Treat refusals, unavailability and rate limits as documented outcomes rather than as faults. Each guide states which of them a caller must handle.
  3. Try the workflow in the workspace with a small input you can verify, then move the same shape into your own client.

About the examples

Developer examples describe routes on an authorised, configured GoCux control-plane base URL. They are request shapes, not a claim that a particular public hostname exposes the API; availability depends on the deployment you are entitled to use.

148 resources

50 of 148