Connect
For: Developers and platform operators wiring an application up to a gateway for the first time.
Gateways | Connect | Gateway Keys | Automation Keys
The Connect page builds a connection recipe: pick a gateway, a workload, and a provider, and it assembles a copy-pasteable snippet and matching curl commands. It doesn't create or change anything — it's a generator that reads your existing gateways, workloads, keys, and providers and composes the right values into place, so you don't have to hand-assemble a base URL, workload ID, and auth header yourself.
Navigation: console.axemere.ai/connect
Table of Contents
- Gateway Selection
- Workload Selection
- Attribution Overrides
- Provider Selection
- Connection Modes
- Gateway Key Authentication
- Try It Out
Gateway Selection
Choose Self-hosted or Managed:
- Self-hosted — enter the
host:portof the gateway you want to connect to (defaults tolocalhost:7080). If your org has more than one self-hosted node registered, enter the address of the specific one you're targeting. - Managed — only shown if your org holds a Growth Pack or Dedicated managed gateway subscription. Shows your org's managed gateway URL (read-only), and if you have any Gateway Keys, a picker to select which one the generated snippet should reference by name — the key's secret value is never shown here, only which key to substitute.
Workload Selection
Pick a workload from your org's registered workloads. If none exist yet, a hint links to creating one — you can also continue without a workload, though most gateway features (attribution, per-workload policy) depend on requests carrying a workload_id.
Selecting a workload determines two things:
- Which connection modes are offered below, based on that workload's
allowed_connection_types. - The workload's default project/account/customer attribution values are shown read-only — these apply automatically server-side to every request from this workload, and won't appear anywhere in the generated URL unless you explicitly override them.
Attribution Overrides
Three optional checkboxes — Project, Account, Customer — let you override the workload's default attribution for this particular connection:
| Field | How to set it |
|---|---|
| Project | Select from your org's registered projects |
| Account | Free-text (cost center / department identifier) |
| Customer | Free-text (SaaS tenant identifier) |
An override only shows up in the generated snippet if it actually differs from the workload's default — if you check a box but leave the value matching the default, nothing changes in the output.
Provider Selection
Choose a provider from the dropdown. By default only providers with an enabled add-on are listed; toggle Show all providers at the top of the page to see the full built-in catalog plus any custom/BYOC connectors you've registered (see Custom Provider).
Connection Modes
Once a provider is selected, tabs appear for each connection mode the workload allows:
| Mode | What it shows |
|---|---|
| Direct API | A POST <host>/v1/actions:execute request against the gateway's own wire format |
| SDK Redirect | An environment variable (e.g. ANTHROPIC_BASE_URL=<host>/proxy/anthropic/...) for pointing a provider SDK's base URL at the gateway instead of the provider directly |
Below the snippet, any provider-specific caveat appears automatically (for example, providers whose SDKs have no base-URL override). For SDK Redirect, a Provider credentials note explains the two ways the provider's own auth can reach the upstream:
- OAuth passthrough — leave the provider's key environment variable unset; the client's own provider session token is forwarded through unchanged.
- BYOK — set the provider's key environment variable to your own key; the gateway forwards it to the provider's
Authorizationheader.
Gateway Key Authentication
Whether a gateway key is required depends on how the gateway is running: managed gateways always require one; self-hosted gateways don't, unless the gateway was started with MVGC_GATEWAY_MODE=managed.
When a key is required, choose how it should be presented in the generated snippet:
| Form | Header/placement |
|---|---|
Authorization: Bearer (default) | Authorization: Bearer <your-axemere-key> |
X-Axemere-API-Key | Custom header |
| Key in URL | /k/<your-axemere-key>/ path segment |
Key-in-URL shows an amber warning: a key embedded in the URL path can end up in access logs and browser history. If you selected a specific key in the Gateway card above, the generated snippet reminds you to substitute your saved secret for the <your-axemere-key> placeholder — the plaintext value itself is never shown again after creation (see Gateway Keys).
Try It Out
An open-by-default Try it out panel shows one or more ready-to-run curl commands matching everything selected above. Gemini shows two examples — its native generateContent surface and its OpenAI-compatible surface — since the two use different request shapes.
Your selections (gateway type, workload, provider, mode, auth form, gateway key) are remembered across visits, so returning to Connect picks up where you left off.
Related: Gateways | Gateway Keys | Automation Keys | Workloads | Providers