> 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/build-connectors-with-a-coding-agent/agent-connectors.md). # Before You Start This material shows how to build an Appmixer connector by directing a coding agent, from an empty directory to a connector running on a live instance. It is for a developer who has an API to integrate and would rather describe the connector than hand-write its manifests. It is not a tour of the manifest format. Where a page needs a manifest key or CLI option, it links to the reference. ## What has to exist already * **An Appmixer instance you can reach**, and an account on it. Installing one is covered in *Appmixer Self-Managed*. * **Node 18.15 or newer.** * **A coding agent** — Claude Code, Cursor, GitHub Copilot, Windsurf or Cline. (GitHub Copilot the coding agent, not Appmixer's AI Copilot; [AI Copilot vs. Appmixer Skills](/build-connectors-with-a-coding-agent/copilot-vs-skills.md) draws the line.) * **A service with an HTTP API you actually need.** Every chapter asks for decisions about scope, which are hard to make about a service picked at random. ## The words this material uses | Term | What it means | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **vendor** | Your namespace: the first segment of every component name, and a property on your Appmixer account. `appmixer` is the scaffolder's default, not a value to keep | | **connector** | Everything that talks to one service — manifests, auth, components | | **module** | A grouping inside a connector, one directory deep; usually just `core` | | **component** | One action or trigger: a manifest plus a behaviour file | | **bundle** | The connector as a versioned package; `bundle.json` carries its version | Every term the guide relies on is in the [Glossary](/build-connectors-with-a-coding-agent/glossary.md). ## The agent does not run unattended "End to end" in the `build-connector` skill means **scope** — build, review, test, publish — not autonomy. There is one hands-off stretch, from scaffolding to offline validation, and then points where the agent stops. **Stops the skill may ask for.** The skill's instructions list several: * where to create the workspace, if you have none; * the connector name, the vendor and the component set; * before CLI tests begin; * the test plan; * before component test runs; * a component that keeps failing; * the push target, before the first `git push`. Expect the stop before the first CLI test and the one at the test plan. The others may not come — name your workspace and vendor in the first prompt rather than waiting to be asked. **Things only a person can do:** * completing an OAuth consent screen — locally in chapter 2, and on the instance in chapter 4; * registering the redirect URI with the service, for each of those; * having an administrator set the `vendor` property on your account. **What the agent may do without stopping.** Nothing in the skills makes the agent ask before it deletes components from your instance or creates records in the account you connected. Some agents stop on their own; some do not. If those decisions are yours, say so in your first prompt, or set your agent to ask before `appmixer remove` — [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md) shows both. {% hint style="warning" %} **There is no "just let it run" mode.** The stops are sentences in the skill; the only way around them is to tell the agent to skip them. Don't, on a first connector — they are where a wrong assumption gets caught early. {% endhint %} ## What it costs **Time.** Plan **an afternoon — two to three hours** — for a first connector of half a dozen components, stops included. **Money.** Chapters 2 to 5 make real API calls against your own account and instance: you spend your agent's tokens and your service's rate limit. Appmixer charges nothing for building a connector. ## How to read this Chapters 1 to 7 are a sequence: each one's exit state is the next one's entry state, and each ends with a command that checks it worked. Chapters 8 and 9 are reference. If you read only one page first, make it [Testing in Three Layers](/build-connectors-with-a-coding-agent/testing.md) — it explains why a connector with green tests can still be wrong. Next: [Install and Sign In](/build-connectors-with-a-coding-agent/setup.md). --- # 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/build-connectors-with-a-coding-agent/agent-connectors.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.