> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/getting-started/connector-with-an-agent.md). # Build a Connector with an Agent You can build an Appmixer connector by directing a coding agent instead of writing the manifests and behaviour files yourself. An afternoon — **two to three hours** — gets you a connector of half a dozen components, tested in three layers and published on your instance. This page is the short version. The full guide is [Build Connectors with a Coding Agent](/build-connectors-with-a-coding-agent/agent-connectors.md); for writing one by hand, see [Build a Custom Connector](/getting-started/custom-connectors.md). ## What you need * An Appmixer instance you can reach, and an account on it. * **Node 18.15 or newer.** * A coding agent: Claude Code, Cursor, GitHub Copilot, Windsurf or Cline. * A service with an HTTP API you actually need, and a link to its documentation. ## Set up, once ```bash npm install -g appmixer # 2.6.0 or newer appmixer url # not the Studio URL appmixer login you@example.com ``` In Claude Code, install the skills — both lines, because adding the marketplace does not install the plugin: ``` /plugin marketplace add Appmixer-ai/appmixer-skills /plugin install appmixer@appmixer-skills ``` In any other agent that supports Open Agent Skills: `npx skills add Appmixer-ai/appmixer-skills`. Then work from a directory containing `src//`, and tell the agent once where the documentation is: > The Appmixer documentation is at docs.appmixer.com. There is an index at `docs.appmixer.com/llms.txt`, and every page has a plain-Markdown version at the same URL with `.md` appended. {% hint style="warning" %} **Read the API URL off your instance, do not type a pattern.** Open **Admin** in Appmixer Studio to reach [Backoffice](/appmixer-backoffice/getting-started.md), then **System → System Configuration**: it prints *Appmixer Studio URL* and *Appmixer API Base URL*. The CLI wants the second one. Give it the Studio URL — the one in your browser history — and every command fails without saying why. {% endhint %} ## The whole workflow is five prompts | # | What you say | What you get | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | 1 | *"I want to build an Appmixer connector for \. Documentation is on \. Start with one component to get my user profile. Authentication is OAuth 2.0."* | The connector scaffolded, and one component that proves authentication works | | 2 | The components you want: name the operations, separate actions from triggers, and say which fields should be dropdowns and which dropdown depends on which | The rest of the connector, validated, with a test plan to approve | | 3 | *"Publish the connector to my Appmixer instance and set it up there so I can connect my \ account."* | The connector published, the OAuth app configured on the instance, and a redirect URI to register | | 4 | *"Import the E2E test flows and run them on the instance."* | Test flows on the instance, running green | | 5 | *"Review the connector before I publish it."* | A read-only audit against the design standards | Shipping a change later is one more prompt: > Don't remove anything on the instance. Bump the version in component.json of every component you changed since the last publish, then publish. That one is worth typing in full. Left to itself, an agent that finds something unexpected on the instance will remove components and publish again, because that is what its instructions tell it to do. ## Where a person is needed * **Completing the OAuth consent screen**, and registering the redirect URI with the provider — twice: once for local testing, once for the instance. * **Connecting the account** in the Designer, which is what the E2E flows then run with. * **Getting your account cleared to publish**, if it is not already: the first publish is refused otherwise, and only an administrator can change that. {% hint style="info" %} Nothing in the skills makes the agent ask before it deletes components from your instance or creates records in the account you connected. If those decisions are yours, say so in your first prompt. {% endhint %} ## What "working" means The agent runs three different tests as it goes, and each answers a different question: | Test | What it answers | | -------------------- | ----------------------------------------------------------------- | | **component test** | Does the code run against the real API and return what we expect? | | **connector verify** | Does what the API returns match what the manifests promise? | | **E2E flow run** | Does it hold up as a flow on the instance, dropdowns and all? | Each one is blind to what the next checks — a component can pass its own test while ignoring every input it is given — so ask for all three results before you call it done. [Testing in Three Layers](/build-connectors-with-a-coding-agent/testing.md) explains why, and what to do when one of them fails. ## Next * The full guide, chapter by chapter: [Build Connectors with a Coding Agent](/build-connectors-with-a-coding-agent/agent-connectors.md) * When something breaks: [When It Doesn't Work](/build-connectors-with-a-coding-agent/troubleshooting.md) * Words that mean two things: [Glossary](/build-connectors-with-a-coding-agent/glossary.md) * Reference implementations to read, and a place to contribute your own: [appmixer-connectors](https://github.com/Appmixer-ai/appmixer-connectors) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.appmixer.com/getting-started/connector-with-an-agent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.