The control plane lives at /profile/integrations, where you store and manage provider credentials in one logged-in surface. The page prioritizes the providers most teams start with — OpenAI, Anthropic, Google, Azure, and Bedrock — and uses an encrypted BYOK security model so provider credentials are handled separately from platform API keys. For Versalist auth itself, use /profile/api-keys instead of model-provider access.

Integrations store provider credentials. API keys authenticate against Versalist. If you want Versalist to call OpenAI, Anthropic, Google Gemini, Azure, Bedrock, or other supported providers using your own infrastructure, use Integrations. If you want the CLI or scripts to authenticate against Versalist challenge APIs, use platform API keys instead. Read platform API key docs.

Foundation-model providers

The integrations page is organized around the providers you are most likely to route inference through. The goal is not to store every possible credential you own. It is to connect the providers that are actually part of your Versalist workflow.

OpenAI and Anthropic

Common starting points for teams running prompt, agent, or evaluation workflows inside Versalist. Manage provider keys.

• Useful for general reasoning and prompt workflows
• Good default providers for many challenge types

Google Gemini, Azure, and Amazon Bedrock

Important when your infrastructure, compliance, or procurement model already points at these providers. Manage provider keys.

• Aligns Versalist usage with existing enterprise infrastructure
• Lets you route work through the provider environment you already trust

Additional providers

The integration system also supports a longer tail of providers for specialized performance or infrastructure preferences. Review specialized providers.

How to add a provider key

The integrations route is meant to stay operational and explicit. Add the key, confirm the provider is enabled, and then leave the page unless your routing or credentials need to change.

1. Open the integrations page. Start from the logged-in provider management route so you are working against the right account. Open integrations.
2. Choose the provider you actually use. Do not configure everything by default. Add the providers your workflow depends on now.
3. Save the credential and check enabled state. A stored provider can still be disabled, which is useful when you want to keep the key on hand without routing traffic to it.
4. Return only when rotation or routing changes. The best integrations pages are boring. If you are living here constantly, your workflow is probably unstable.

What's live, what's planned

Today you can bring your own provider keys and route model calls through your own accounts. Bringing your own model endpoints or your own compute is planned work — listed below so you can tell the difference, not because it ships today.

A provider showing up in our directory is not the same as Versalist running on it. We list providers that matter to the stack so you can see the landscape. Whether Versalist can actually execute against a given provider depends on which row below applies — bring-your-own keys is live, the rest is on the roadmap.

Bring your own keys

Store your provider credentials and route supported model calls through your own accounts. Live today.

• Credentials and on/off state live in /profile/integrations
• Your provider keys stay separate from Versalist platform API keys

Bring your own model endpoint

Point Versalist at an OpenAI-compatible or provider-hosted endpoint your team already runs. Not live yet.

• For teams already operating their own model surface
• Will be called out explicitly here once the adapter ships

Bring your own compute

Run container-shaped rollouts, GPU jobs, and training workloads on your own clusters or serverless GPU. Not live yet.

• Aimed at long-running episodes, training jobs, and artifact capture
• Requires the runtime adapter, job ledger, and rollback path to land first

Listed ≠ executable

AI Tools entries explain why a provider matters in this space. They do not imply Versalist can run against that provider unless one of the rows above says so.

• Unshipped surfaces are labeled “planned”
• Partner-tier language stays out until there are real runs to point at

Related external systems

Some integrations are about inference providers. Others are about the systems your work already lives in. Keep those roles separate so the page remains understandable.

GitHub

GitHub matters for repo-linked work, challenge submissions, and account linking in developer-first flows. Review linked auth providers.

Platform API keys

Use platform keys for CLI, MCP, and challenge APIs. They are related to integrations, but they are not a provider connector. Manage platform API keys.

Docs and troubleshooting

When routing or auth feels unclear, use the docs rather than trying to infer the security model from the UI alone. Read API docs.

Operational guidance

Integrations should help you keep control of routing and credentials, not turn into a hidden source of cost drift or auth confusion. Treat the page as a routing contract.

Use only the providers you intend to route to

A smaller active provider set is easier to reason about than a page full of stale enabled keys.

Rotate keys when environments change

If teams, billing ownership, or provider policy changes, update the integration rather than hoping the old key keeps working forever.

Keep platform auth and provider auth separate

If a CLI or MCP flow fails, check platform API keys. If a routed model call fails, check provider integrations.

Troubleshooting

Integration problems usually come from one of three places: the wrong provider was enabled, the credential is stale, or the user is actually looking at the wrong auth layer entirely.

1. Confirm you are in the right auth layer. Provider credential issue and platform API-key issue are different problems with different fixes. Read API-key distinction.
2. Check whether the provider is enabled. A stored key that is disabled will not route traffic the way you expect.
3. Rotate or re-enter the credential. If the provider should be active, update the stored key rather than repeatedly retrying a stale one.
4. Escalate when the issue is workflow-level. If the problem affects the product flow rather than a single key, use the support or feedback routes. Open support FAQ.