> 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/on-the-instance.md). # On the Instance So far everything ran on your machine. This chapter puts the connector on your instance, so that a user can connect an account in the Designer and chapter 5's third layer has something to run flows against. Three things happen, in order: the connector is **published**, the instance gets **its own copy of your OAuth app's credentials**, and **one account is connected**. The first can fail before you type anything; the last needs a person. Use a development instance, not the one your users work on. Every publish after this one follows [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md). ## The prompt > Publish the connector to my Appmixer instance and set it up there so I can connect my Eventbrite account. The Appmixer CLI is already logged in to the instance. Expect the agent to publish without asking, configure the OAuth app on the instance, read the instance's redirect URI, and then hand two things back: registering that URI with the provider, and connecting the account. If your account is not an administrator, the agent may not know the route that works for you — it is spelled out below. ## Before the first publish: the vendor property Your Appmixer account must carry a `vendor` property matching the vendor in your manifests: components named `acme.eventbrite.core.FindEvents` need `vendor` set to `acme`. An administrator sets it in Backoffice, on the Users page — see [Publish your component](/appmixer-cli/appmixer-cli.md#publish-your-component) and [Basic Structure](/building-connectors/basic-structure.md). Check your account first: ```bash appmixer user me # vendor: the list you may publish under; scope: whether you are an administrator ``` {% hint style="warning" %} **Administrators skip the vendor check.** A successful publish from an admin account says nothing about a colleague on an ordinary one. If someone without admin rights will publish this connector, have them do it once. {% endhint %} Without the right vendor, publishing fails in one of two ways: | Your account | What you see | When | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | | no `vendor` at all | `[ERROR]: User is not allowed to create components, no vendor assigned. (status 500)` | at once, before any upload | | a `vendor`, but not yours | `Publishing failed with following error:` then `Vendor mismatch in component.json, allowed vendors are: 'acme', but 'appmixer' found.` | after the upload | Both exit `1`. The first is a permission refusal despite the 500; the second names whichever manifest the check reached first. Neither is something the agent can fix: an administrator sets the vendor, or you rename the connector ([Scope and Research](/build-connectors-with-a-coding-agent/research.md)). ## Publish ```bash appmixer pack ./src// -o .zip appmixer publish .zip ``` ``` Publishing archive: /path/to/.zip Publishing started at 2026-09-21T11:42:50.520Z to https://api. Published in 4.29s. ``` `pack` leaves `artifacts/` out, so test plans, samples and E2E flows stay in your repository. Delete the zip afterwards. {% hint style="warning" %} **Publish as the right user.** "Already logged in" can mean logged in as somebody else: in CLI 2.6.0, `appmixer login ` for a different user prints exactly that, switches the alias and leaves the session as it was. `appmixer alias ` prints `Logged in as `; the bare `appmixer alias` listing does not. Read it back before you publish. {% endhint %} ## Give the instance your OAuth app The local login took the client id and secret from the command line. The instance has neither, and cannot start an OAuth flow until it does — nothing on your machine will tell you. | You are | Command | Who can connect accounts with it | | ---------------- | --------------------------------------------------------------------- | -------------------------------- | | an administrator | `appmixer service-config set :` | every user of the instance | | anyone else | `appmixer user-service-config set : ` | only you | For an administrator: ```bash appmixer service-config set : \ -d '{"clientId":"","clientSecret":""}' appmixer service-config validate : ``` Anyone else gets `[ERROR]: Insufficient scope (status 403)` from `service-config` and stores the same values as a *custom OAuth config* instead: ```bash appmixer user-service-config set : -f oauth-app.json ``` ``` User service config acme:eventbrite/eventbrite-app successfully saved. ``` `oauth-app.json` holds `{"clientId": "…", "clientSecret": "…"}`; `-d ''` and stdin also work, but a file you delete afterwards keeps the secret out of your shell history and out of the conversation. Your configs are listed under **Custom OAuth Configs** in the Appmixer app. A per-user config is enough to build and test; shipping to other users needs an administrator to run `service-config set` once. ## Point the redirect URI at the instance The instance builds its redirect URI like the CLI — from the service name, no vendor, no colon: ``` https://api./auth//callback ``` Read the exact value off an authorization URL rather than typing it: ```bash TICKET=$(appmixer auth ticket --json | jq -r .ticket) appmixer auth url . "$TICKET" ``` Use the **dotted** name. The colon form, which the command's own help shows, is refused with `Missing vendor or service. (status 400)`. Register the `redirect_uri` value with the provider. Eventbrite keeps only one redirect URI per key, so this replaces the local one from chapter 2 and local `test auth login` stops working until you swap it back; the token you already have keeps working. Providers that accept several URIs avoid the swap. Connecting before the provider has the new value fails with `Redirect URI hostnames must match`. ## The human gate: connect the account 1. Open the Appmixer app **as the user that saved the OAuth config** — a per-user config is invisible to anyone else. 2. Add any component of your connector to a flow and connect an account. 3. If the dialog offers a choice of OAuth config, pick yours. 4. Approve on the provider's consent screen. The CLI can run the same exchange: ```bash TICKET=$(appmixer auth ticket --json | jq -r .ticket) appmixer auth url . "$TICKET" --config-name # open it, approve appmixer auth ticket-status "$TICKET" ``` {% hint style="info" %} **Re-authorizing updates the existing account in place** — same id, same name. If an account stops validating, authorize it again rather than deleting it; its flows stay bound. {% endhint %} ## Verify ```bash appmixer account ls | grep # the account exists appmixer account test # validateAccessToken() runs live ``` ``` Account is valid. ``` Then open a component with dropdowns in the Designer and check that they fill — for Eventbrite, the organization list, then the events of the chosen organization. The CLI cannot exercise dropdowns, and a valid account says only that the credential works, not that the components using it do. Next: [Testing in Three Layers](/build-connectors-with-a-coding-agent/testing.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/on-the-instance.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.