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 sk-actions-custom-provider skill. 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.

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 as the request body:

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.

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 API to get the provider identifier from the response before sending the update request.

Use the updated JSON body from Auth patterns and the provider identifier in the update request:

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 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 API to get the provider identifier from the response before sending the delete request.

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