> 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/glossary.md). # Glossary The CLI, the engine and the Designer do not always use the same words. This page lists every term the guide relies on and where it matters; where two words mean one thing, or one word two things, both are here. ## Naming what you build ### vendor Your namespace: the first segment of every component name, and a property on your Appmixer account listing the vendors you may publish under. `appmixer` is the scaffolder's default, not a value to keep. Admin accounts skip the vendor check. See [Scope and Research](/build-connectors-with-a-coding-agent/research.md) and [On the Instance](/build-connectors-with-a-coding-agent/on-the-instance.md). ### connector, service **One thing, two names.** The skills and this guide say *connector*: everything that talks to one external service. The engine and [Basic Structure](/building-connectors/basic-structure.md) say *service*, and its manifest is `service.json`. Where a redirect URI or a colon-separated reference says ``, read "connector". ### module A grouping inside a connector, one directory deep. Most connectors have exactly one, called `core`. A module with its own `module.json` appears as a separate app — Gmail and Calendar are modules of one Google service. ### app What the Designer shows as one entry in its component panel, and what AI Copilot lists when it looks for building blocks: a service, or a module that has its own `module.json`. The CLI does not use the word. ### component One action or trigger: a `component.json` manifest plus a behaviour file. The thing a user drags into a flow. ### component type, and its three spellings A component's full name — `...` — is its **type**. The same identity is written three ways, depending on where you are: | Spelling | Example | Used by | | -------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | dots | `acme.eventbrite.core.FindEvents`, `acme.eventbrite` | component names, `appmixer remove`, `appmixer component get`, `appmixer download`, `appmixer auth url`, `/appmixer:review-connector` | | colons | `acme:eventbrite`, `acme:eventbrite:core` | `auth.service` in a manifest, `appmixer service-config`, `appmixer user-service-config`, `appmixer e2e … -c` | | slashes | `src/acme/eventbrite/core/FindEvents/` | the workspace on disk, `appmixer test component`, `appmixer pack` | `appmixer test component` takes a **directory**, not a type. `appmixer auth url` takes the **dotted** form, although its help shows colons. See [Your First Component](/build-connectors-with-a-coding-agent/first-component.md) and [On the Instance](/build-connectors-with-a-coding-agent/on-the-instance.md). ### bundle The connector as a versioned package: `bundle.json` holds its `name`, `version` and `changelog`. What happens to a component on republish is decided by that component's own `component.json` version, not the bundle's. See [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md). ### archive The zip that `appmixer pack` builds and `appmixer publish` uploads. ## Where things live ### workspace — two meanings **In this guide, a directory**: any directory containing `src//`, where you and your agent work. `APPMIXER_SKILL_CONNECTORS_DIR` points at one from elsewhere. See [Install and Sign In](/build-connectors-with-a-coding-agent/setup.md). **On an instance, a** [**user group**](/api/user-groups.md): a shared context owning flows, data stores and files. `--workspace` and `APPMIXER_WORKSPACE` mean this kind. The two are unrelated. ### instance One Appmixer installation. The CLI reaches it through its **API Base URL**, never through the Designer URL. Backoffice prints both, under **System → System Configuration**. ### alias The CLI's name for one instance together with your session on it. Switching an alias moves the URL and the session at once. See [Install and Sign In](/build-connectors-with-a-coding-agent/setup.md). ### Designer, Backoffice The **Designer** is where flows are built, and where a published connector appears in the component panel. **Backoffice** is the administration UI — where the `vendor` property is set on a user. ## Authentication ### auth module `auth.js`: declares the connector's auth type and how to obtain and check a credential. Its contents depend on the type — for `apiKey`, `definition` carries an `auth` map of the fields a user fills in; for `oauth2`, the endpoints of the OAuth exchange. `definition` may be an object or a function for any type. See [Authentication](/building-connectors/authentication.md) in Building Connectors. ### account A credential stored on the instance for one user and one connector, which that user's flows run with. Re-authorizing an account updates it in place — same id, same name. ### local credential store Where `appmixer test auth login` keeps the credential for local tests: `~/.config/configstore/appmixer.json`, the same file as your CLI session. Do not edit it by hand. Agents may read tokens out of it to call the API directly. ### service configuration Instance-wide settings for one connector; for OAuth, the app's client id and secret. `appmixer service-config set :` — administrators only. Without it, or a custom OAuth config, the instance cannot start an OAuth flow. See [On the Instance](/build-connectors-with-a-coding-agent/on-the-instance.md). ### custom OAuth config The same client id and secret, stored for one user only: `appmixer user-service-config set : `. How a non-admin account connects an OAuth account; listed under **Custom OAuth Configs** in the Appmixer app. See [On the Instance](/build-connectors-with-a-coding-agent/on-the-instance.md). ### redirect URI Where the provider sends the browser back after consent. Appmixer builds it from the **service** part of the name — `/auth//callback` — so `appmixer:google:gmail` calls back on `/auth/google/callback`. See [On the Instance](/build-connectors-with-a-coding-agent/on-the-instance.md). ## Testing ### flow An automation on an instance: components wired together, stored as a JSON flow descriptor. Integration templates and automations are both flows internally. See [Flow](/building-connectors/flow.md). ### E2E flow An ordinary flow marked as a test through its `customFields` (`category=E2E_test_flow`, `connector`, `name`). The skill writes them to `artifacts/test-flows/`; `appmixer e2e import`, `run` and `list` handle them. See [Testing in Three Layers](/build-connectors-with-a-coding-agent/testing.md). ### FIX BRIEF What `appmixer e2e run --fix` emits, with exit code `2`, when a run fails and none of its deterministic fixes applies. Addressed to the agent; starts with `═══ NEEDS_FIX — fix brief for the calling agent ═══`. See [Testing in Three Layers](/build-connectors-with-a-coding-agent/testing.md#the-loop). ### Flow Test Mode, `test()` A trigger's `test()` method returns one real example, so a flow can be tested in the Designer without waiting for the event to happen. `appmixer test component --test` calls it locally. ### test plan The dependency-ordered list of component tests the skill writes before running any, in `artifacts/ai-artifacts/test-plan.json`. It also says what the agent will create in your account — the one point where it reliably asks first. ### `verify.json`, samples `artifacts/verify.json` is the spec for `appmixer connector verify`: fixture recipes and enum round-trips. `artifacts/samples/` holds the sanitized output shapes `--record` saves, for `--offline` checks. ### negative control A test run with the old path deliberately removed, so that a pass can only mean the new path works. The one test that tells an auth migration apart from a coincidence. See [Day-to-Day Work](/build-connectors-with-a-coding-agent/daily.md#run-the-negative-control). ## Review and publishing ### finding, waiver A **finding** is one row of the review's output — `error`, `warning` or `info`. A **waiver** is a finding you decided not to fix, written down with the reason. See [Review Before Publishing](/build-connectors-with-a-coding-agent/review.md). ### threshold ratchet How `appmixer connector validate` tolerates existing debt: a rule with a recorded threshold fails only when its count rises above it; a rule without one fails on any violation. See [Scope and Research](/build-connectors-with-a-coding-agent/research.md). ### retired copies What publishing leaves behind: every earlier copy of a component stays in storage, and nothing is served from it. `appmixer component ls -m` shows the version that is served; `appmixer component get` hands you the whole history, under one path inside the zip. See [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md). ## Working with the agent ### skill A packaged set of instructions a coding agent loads for one kind of task. This guide uses `build-connector`, `test-connector` and `review-connector`; in Claude Code they come as the `appmixer` plugin, invoked as `/appmixer:`. ### stop A point where the agent halts for you: one the skill asks for, which may not happen, or a step only a person can do, which always does. See [Before You Start](/build-connectors-with-a-coding-agent/agent-connectors.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/glossary.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.