API operations for enabling and disabling provider connections
The v1/providers API includes endpoints to enable or disable integrations by provider id. This allows you to temporarily pause data extraction and synchronization for specific providers when needed, without deleting the configuration.
Obtain the provider_id value from (GET /api/v1/providers), filtering by type if needed.
Activate a provider connection that was disabled.
Deactivates a provider connection until it is-renabled, preserving the configured settings.
curl -X PUT \
"https://{tenant}.vezacloud.com/api/v1/providers/{id}:enable" \
-H "accept: application/json" \
-H "Authorization: Bearer {your_api_key}"curl -X PUT \
"https://{tenant}.vezacloud.com/api/v1/providers/{id}:disable" \
-H "accept: application/json" \
-H "Authorization: Bearer {your_api_key}"Veza API key for authentication. Generate keys in Administration > API Keys.
OK
Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
The type of the serialized message.
PUT /api/v1/providers/{id}:enable HTTP/1.1
Host: your-tenant.vezacloud.com
Authorization: Bearer YOUR_SECRET_TOKEN
Accept: */*
{}Veza API key for authentication. Generate keys in Administration > API Keys.
OK
Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
The type of the serialized message.
PUT /api/v1/providers/{id}:disable HTTP/1.1
Host: your-tenant.vezacloud.com
Authorization: Bearer YOUR_SECRET_TOKEN
Accept: */*
{}