> **Building with AI coding agents?** If you're using an AI coding agent, install the official Scalekit plugin. It gives your agent full awareness of the Scalekit API — reducing hallucinations and enabling faster, more accurate code generation.
>
> - **Claude Code**: `/plugin marketplace add scalekit-inc/claude-code-authstack` then `/plugin install <auth-type>@scalekit-auth-stack`
> - **GitHub Copilot CLI**: `copilot plugin marketplace add scalekit-inc/github-copilot-authstack` then `copilot plugin install <auth-type>@scalekit-auth-stack`
> - **Codex**: run the bash installer, restart, then open Plugin Directory and enable `<auth-type>`
> - **Skills CLI** (Windsurf, Cline, 40+ agents): `npx skills add scalekit-inc/skills --list` then `--skill <skill-name>`
>
> `<auth-type>` / `<skill-name>`: `agent-auth`, `full-stack-auth`, `mcp-auth`, `modular-sso`, `modular-scim` — [Full setup guide](https://docs.scalekit.com/dev-kit/build-with-ai/)

---

# Managing providers

Use this page to create, list, update, promote, and delete custom providers in Scalekit.

Create providers in `Dev` first, validate the definition, and then use the same definition for updates or Production rollout.
**Recommended approach:** The recommended way to manage providers is with the <a href="https://github.com/scalekit-inc/skills/tree/main/skills/agent-auth/sk-actions-custom-provider" target="_blank" rel="noopener noreferrer">`sk-actions-custom-provider` skill</a>. It keeps payload generation, review, and promotion consistent across Dev and Production.

Use it to:

- Infer the provider auth type
- Generate the provider payload
- Review existing providers before create or update
- Show diffs before updates
- Move provider definitions from Dev to Production
- Prepare the delete curl for a provider

Whenever the skill shows you the final provider payload, review the values carefully before approving or running the next step.

If you prefer to manage custom providers with the APIs directly, use the `curl` commands on this page and the JSON bodies from [Auth patterns](/agent-auth/bring-your-own-provider/auth-types-and-patterns).

Before using the `curl` examples on this page, make sure:

- `SCALEKIT_ENVIRONMENT_URL` points to the Scalekit environment where you want to manage the provider
- `env_access_token` contains a valid environment access token for that environment

## Create a provider

Create the provider in `Dev` first. Share the provider name, Scalekit credentials, API docs, auth docs, and base API URL if you already know it. The skill will infer the auth pattern, generate the provider payload, and help you create it.

Use one of the JSON payloads from [Auth patterns](/agent-auth/bring-your-own-provider/auth-types-and-patterns) as the request body:

```bash
curl --location "$SCALEKIT_ENVIRONMENT_URL/api/v1/custom-providers" \
  --header "Authorization: Bearer $env_access_token" \
  --header "Content-Type: application/json" \
  --data '{...}'
```

After the provider is created, create a connection in the Scalekit Dashboard and continue with the standard Agent Auth flow.

## List providers

List existing providers before you create or update one. This helps you confirm whether the provider already exists and whether you should create a new provider or update an existing one.

```bash
curl --location "$SCALEKIT_ENVIRONMENT_URL/api/v1/providers?filter.provider_type=CUSTOM&page_size=1000" \
  --header "Authorization: Bearer $env_access_token"
```

## Update a provider

When a provider changes, use the skill to compare the current provider with the proposed payload. Review auth fields, scopes, and proxy settings carefully before applying the update, because these values affect how future authorization and proxy calls behave.

Use the [List providers](#list-providers) API to get the provider `identifier` from the response before sending the update request.

Use the updated JSON body from [Auth patterns](/agent-auth/bring-your-own-provider/auth-types-and-patterns) and the provider `identifier` in the update request:

```bash
curl --location --request PUT "$SCALEKIT_ENVIRONMENT_URL/api/v1/custom-providers/$PROVIDER_IDENTIFIER" \
  --header "Authorization: Bearer $env_access_token" \
  --header "Content-Type: application/json" \
  --data '{...}'
```

## Move a provider from Dev to Production

Use the `Dev` provider as the source of truth. The skill can locate the matching provider in `Dev`, compare it with `Production`, and prepare the correct action from there.

In practice, this means:

- fetch the provider definition from `Dev`
- review the payload
- create it in `Production` if it does not exist
- update it in `Production` if it already exists

Use the same JSON body from [Auth patterns](/agent-auth/bring-your-own-provider/auth-types-and-patterns) for the Production create or update request. This keeps the provider definition consistent between environments.

## Delete a provider

To delete a provider, resolve the correct provider identifier first. If the provider is still in use, remove the related connections or connected accounts before retrying the delete flow.

Use the [List providers](#list-providers) API to get the provider `identifier` from the response before sending the delete request.

```bash
curl --location --request DELETE "$SCALEKIT_ENVIRONMENT_URL/api/v1/custom-providers/$PROVIDER_IDENTIFIER" \
  --header "Authorization: Bearer $env_access_token"
```

---

## More Scalekit documentation

| Resource | What it contains | When to use it |
|----------|-----------------|----------------|
| [/llms.txt](/llms.txt) | Structured index with routing hints per product area | Start here — find which documentation set covers your topic before loading full content |
| [/llms-full.txt](/llms-full.txt) | Complete documentation for all Scalekit products in one file | Use when you need exhaustive context across multiple products or when the topic spans several areas |
| [sitemap-0.xml](https://docs.scalekit.com/sitemap-0.xml) | Full URL list of every documentation page | Use to discover specific page URLs you can fetch for targeted, page-level answers |
