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.

The provider_id value should be obtained from the provider listing APIs (e.g., /api/v1/providers/aws for AWS providers)

Enable Provider

Activate a provider connection that was disabled.

Disable Provider

Deactivates a provider connection until it is-renabled, preserving the configured settings.

The Veza management API enables internal tooling to automate administration of cloud providers and data sources. Each supported provider has endpoints to get, create, and modify the current configurations, which can be useful when integrating with environments spanning many provider accounts.

Notes

• A data plane ID is required when adding a custom provider. This value refers to the Insight Point used for discovery, or the GUID of the built-in data plane. To get all available IDs, navigate to Administration > Insight Point. Unless you have deployed an Insight Point within your environment, the only entry will be for the internal data plane.

• If a request is unsuccessful, an error message will provide additional details and troubleshooting steps.

Authentication

You can issue new API keys from Administration > API Keys > . Provide the key as the bearer auth token in the header of each request.

Users must have the role to add/modify provider configurations. Configurations can be viewed by users with the operator role.

Sample Integrations and Tools

Register Accounts - Use the management API to add multiple AWS accounts from CSV.

Veza Python Client - Simple Python class for making REST API calls to Veza.

Cloud Formation Stacks - Configure multiple AWS accounts for Veza discovery by enabling the required assume role operations and IAM permissions.

Open Authorization APIs

If your organization uses applications, data sources, or identity providers not natively supported by Veza, you may be able to add them to your data catalog using . You will need to query the provider to retrieve entity and permissions metadata and push the payload to Veza for parsing in a template format.

Endpoints for administering custom resources (/providers/custom/*)are described in .

Endpoint

Description

Pause discovery and extraction for a data source. This will cancel all pending extractions for the specified data source.

API Reference

Path Parameters

Request Examples

Response Examples

Standard Response:

Endpoint

Description

Returns status and configuration details for an individual data source by its ID.

Endpoint

Description

Returns the current parsing status for a specific data source, including information about the last parse operation and any errors that occurred.

API Reference

Path Parameters

Request Examples

Response Examples

Standard Response:

Endpoint

Description

Resume monitoring and queue the data source for extraction. This will re-enable a previously disabled data source and schedule it for data collection.

Endpoint

Description

Returns the current synchronization status for a specific data source, including information about the last sync operation and any errors that occurred during data extraction.

Endpoint

Description

Update the name for a given data source ID. This endpoint allows you to modify the display name of an existing data source.

API Reference

Path Parameters

Request Body

Request Examples

Response Examples

Standard Response:

Endpoint

Description

Returns the properties and status for all data sources. When filtering is applied, only data sources matching the filter will be returned.

Each cloud provider will have one or more associated data sources. Each represents a discrete instance of a service that Veza connects to for the discovery and extraction of authorization metadata.

The provider under /providers/aws/{id}, for example, may have an associated EC2 data source, represented as:

You can use the API to get or update data source records, or enable and disable individual data sources.

Endpoint

Description

Returns filtered by their supported action types, entity types, and relationship types. This endpoint helps you find datasources that can perform specific lifecycle management operations.

Endpoint

Description

Returns detailed information for a specific lifecycle management datasource by its ID, including its supported capabilities, available actions, syncable attributes, and grantable entitlements.

API Reference

Path Parameters

Request Examples

Response Examples

For detailed information about the response fields, see the documentation.

Endpoint

Description

Lists all data sources that have enabled lifecycle management and their detailed capabilities. This endpoint shows which systems can be used as sources of identity information and as targets for access management operations in Veza Lifecycle Management.

Use this endpoint to:

• Discover which datasources support lifecycle management

• View the capabilities each datasource provides

• Get datasource IDs needed for other lifecycle management operations

• Identify available actions, syncable attributes, and grantable entitlements for each datasource

API Reference

Query Parameters

Request Examples

Response Examples

Response Fields

Basic Datasource Information

• id: Unique identifier for the datasource

• name: Human-readable name of the datasource

• provider_type: The type of integration (e.g., SCIM, WORKDAY, ACTIVE_DIRECTORY)

• external_id: External system identifier or endpoint URL

Supported Capabilities

The supported_capabilities field indicates what operations each datasource can perform:

• IDENTITY_SOURCE: Can provide identity information for lifecycle management

• ACCESS_TARGET: Can receive and execute access management operations

Available Actions

The available_actions array details specific lifecycle management operations supported:

• action_type: Type of action (e.g., MANAGE_RELATIONSHIPS)

• description: Human-readable description of the action

• supported_entity_types: Entity types this action can work with (User, Group, etc.)

• supported_relationship_types: Relationship types this action can manage (MemberOf, etc.)

Syncable Attributes

The syncable_attributes array shows which entity attributes can be synchronized:

• entity_type: The type of entity (User, Group, etc.)

• attributes: Array of attribute definitions including:

  • name: Attribute name in the target system

  • type: Data type (string, array, boolean, etc.)

Grantable Entitlements

The grantable_entitlements array shows what access can be granted through this datasource:

• entity_type: Type of entity that can grant access (typically Group)

• entitlement_type: Type of entitlement relationship (MemberOf, etc.)

• description: What access is granted through this entitlement

Overview

The Data Source Scheduling Configuration APIs allow administrators to configure advanced scheduling options for individual data sources, including:

• Priority scheduling: Assign priorities (1-100) to ensure extraction jobs are processed ahead of standard data sources

• Scheduled extraction times: Define specific times of day when extractions should occur (in 30-minute intervals)

• Day-of-week scheduling: Restrict extractions to precise days of the week

These APIs are intended primarily for use with Veza Lifecycle Management to ensure critical data sources (such as HR systems) are refreshed at predictable times to support downstream automation workflows.

Examples

Source of Identity Scheduling

Configure HR system data sources to extract at specific times to ensure identity data is current before provisioning workflows execute:

Prevent Extraction During Business Hours

Schedule non-critical extractions only on weekends to reduce workload during business hours:

Endpoints

Create or Update Scheduling Configuration

Endpoint

Description

Creates or updates the scheduling configuration for a specific data source. If a configuration already exists for the data source, it will be updated with the new values; otherwise, a new configuration will be created.

Path Parameters

Request Body

The request body contains the configuration fields directly (no wrapper object needed):

Validation Rules

• Priority: Must be between 1-100 (where 100 is the highest priority)

  • When scheduled_extraction_times are configured, priority must be 100 to ensure jobs are processed closest to the configured times

  • Priority 1-99 can be used without schedules for edge cases requiring a higher priority than standard periodic scheduling

Request Examples

Response Examples

Standard Response:

Error Response (Invalid Time Format):

Error Response (Limit Reached):

Get Scheduling Configuration

Endpoint

Description

Retrieves the scheduling configuration for a specific data source.

Path Parameters

Request Examples

Response Examples

Standard Response:

Error Response (Not Found):

List Scheduling Configurations

Endpoint

Description

Returns all scheduling configurations across all data sources in your organization.

Query Parameters

Request Examples

Response Examples

Standard Response:

Delete Scheduling Configuration

Endpoint

Description

Removes the scheduling configuration for a specific data source. The data source will revert to standard scheduling behavior.

Path Parameters

Request Examples

Response Examples

Standard Response:

Related APIs

• - Get data source IDs for configuration

• - View data source details and status

• - Automated identity lifecycle workflows

Overview

This guide explains how to disable specific AWS services across multiple AWS integrations (providers) using the Veza API. Limiting AWS service extraction can reduce processing overhead, help teams focus on relevant services, or exclude analytics platforms like DATABRICKS that may not be deployed or required for visibility in Veza. This is particularly useful for organizations with many AWS accounts who need to disable unused services at scale.

In the JSON AWS provider configuration, the services array acts as an allow list that controls which AWS services Veza will discover and extract:

• Empty array [] = All available AWS services are enabled for discovery

• Populated array = Only the listed services are enabled; all others are disabled

To disable specific services, you must populate the array with only the services you want to monitor.

Before you start

Before you update AWS provider services, ensure:

• You have API access credentials for your Veza instance (see for API key setup)

• You have the VEZA_TOKEN environment variable configured

• You have the VEZA_URL environment variable set to your instance (e.g., https://yourcompany.cookiecloud.ai)

• You have appropriate permissions to modify provider configurations

Disable specific AWS services across providers

Step 1: Discover your current AWS providers

First, retrieve all AWS provider configurations to understand your current setup:

Understanding the response:

• Providers with empty services: [] arrays have ALL services enabled

• Providers with populated services arrays only extract the listed services

• Note the id, name, and account_id fields for providers you want to modify

Example response structure:

Step 2: Identify target providers and services

1. Identify which providers to modify based on:

   • Provider names that match your AWS accounts

   • Account IDs that correspond to your AWS accounts

   • Current services configuration

Step 3: Test with a single provider

Before updating all providers, test with one provider first:

Verify the change:

Check that the response shows your desired services array.

Step 4: Apply to multiple providers

Manual approach (recommended for small numbers)

Update each provider individually using their specific IDs:

Bulk approach (for many providers)

Create a script for bulk updates. Use with caution as this affects all AWS providers:

Step 5: Verify changes

After updating providers, verify the changes took effect:

Reversing changes

Re-enable all services

To return a provider to monitoring all services:

Modify service configuration

To change which services are monitored:

Available AWS services

The following AWS services can be included in the services array:

• S3 - Simple Storage Service

• RDS_POSTGRES - PostgreSQL databases

• RDS_MYSQL - MySQL databases

Important notes:

• Service availability may vary by Veza version and configuration

• Some services may require specific permissions or setup

• When in doubt, check your Veza UI to see which services are available for your AWS providers

See also

You can manage Veza integrations using the management API and a Veza admin API key.

Use these operations to configure and manage cloud platform integrations including AWS, Azure, Google Cloud, Snowflake, SQL Server, and Trino providers. Each provider type has specific configuration requirements and optional parameters for controlling discovery scope.

Provider Types

Veza supports the following provider types:

• AWS: Amazon Web Services accounts with support for IAM, S3, RDS, Redshift, and other services

• Azure: Microsoft Azure tenants including Active Directory and SharePoint Online

• Google Cloud: Google Cloud Platform projects and Google Workspace domains

• Snowflake: Snowflake data warehouses and databases

• SQL Server: Microsoft SQL Server instances

• Trino: Trino clusters with file-based access control

For detailed integration guides, see the .

Authentication

You will need an API token with administrator permissions to manage provider configurations. See for details.

Common Provider Properties

All provider configurations share these common properties:

• id (String): Unique identifier for the provider configuration

• vendor_id (String): Provider-specific identifier (e.g., AWS account ID)

• name (String): Display name for the provider

AWS Providers

AWS Provider Object Schema

AWS provider configurations include account credentials, regions, and service-specific settings:

AWS Configuration Fields

• account_id (String): AWS account ID (12-digit number)

• credentials_type (String): Authentication method - STATIC, EC2_INSTANCE_PROFILE, or ASSUME_CUSTOMER_ROLE

• access_key_id

AWS Service Discovery Options

Available service values for the services array:

• IAM: Identity and Access Management

• S3: Simple Storage Service

• RDS: Relational Database Service

AWS Resource Filtering

Use allow/deny lists to control which resources are discovered:

• s3_bucket_allow_list: S3 bucket names to include (supports wildcards)

• s3_bucket_deny_list: S3 bucket names to exclude

• rds_database_allow_list: RDS database names to include

For detailed AWS setup instructions, see .

AWS API Operations

List AWS Providers

Create AWS Provider

Get AWS Provider

Update AWS Provider

Delete AWS Provider

Get AWS Trust Policy

Check AWS Policy

Azure Providers

Azure Provider Object Schema

Azure provider configurations include tenant authentication and service settings:

Azure Configuration Fields

• tenant_id (String): Azure Active Directory tenant ID

• client_id (String): Application (client) ID for service principal

• client_secret (String): Client secret for authentication

For detailed Azure setup instructions, see .

Azure API Operations

List Azure Providers

Create Azure Provider

Get Azure Provider

Update Azure Provider

Delete Azure Provider

Google Cloud Providers

Google Cloud Provider Object Schema

Google Cloud provider configurations include service account credentials and project settings:

Google Cloud Configuration Fields

• credentials_json (String): Service account key JSON

• customer_id (String): Google Workspace customer ID

• workspace_email (String): Workspace user email for service account impersonation

For detailed Google Cloud setup instructions, see .

Google Cloud API Operations

List Google Cloud Providers

Create Google Cloud Provider

Get Google Cloud Provider

Update Google Cloud Provider

Delete Google Cloud Provider

Snowflake Providers

Snowflake Provider Object Schema

Snowflake provider configurations include connection details and database filtering:

Snowflake Configuration Fields

• account_locator (String): Snowflake account locator (e.g., "xy12345")

• region (String): Cloud region for the Snowflake account

• cloud (String): Cloud provider ("aws", "azure", or "gcp")

For detailed Snowflake setup instructions, see .

Snowflake API Operations

List Snowflake Providers

Create Snowflake Provider

Get Snowflake Provider

Update Snowflake Provider

Delete Snowflake Provider

SQL Server Providers

SQL Server Provider Object Schema

SQL Server provider configurations include connection details and database filtering:

SQL Server Configuration Fields

• host (String): SQL Server hostname or IP address

• port (Integer): Port number (typically 1433)

• username (String): SQL Server username

For detailed SQL Server setup instructions, see .

SQL Server API Operations

List SQL Server Providers

Create SQL Server Provider

Get SQL Server Provider

Update SQL Server Provider

Delete SQL Server Provider

Trino Providers

Trino Provider Object Schema

Trino provider configurations include cluster connection details and S3 access control file settings:

Trino Configuration Fields

• host (String): Trino coordinator hostname

• port (Integer): Trino coordinator port (typically 8080 or 8443)

• username (String): Trino username

S3 Object Configuration

The aws_s3_object_config object contains:

• access_key (String): AWS access key ID

• secret_key (String): AWS secret access key

• region (String): S3 bucket region

For detailed Trino setup instructions, see .

Trino API Operations

List Trino Providers

Create Trino Provider

Get Trino Provider

Update Trino Provider

Delete Trino Provider

Error Handling

All provider API operations return standard HTTP status codes:

• 200 OK: Request successful

• 400 Bad Request: Invalid request parameters or payload

• 401 Unauthorized: Invalid or missing API token

• 403 Forbidden: Insufficient permissions

Error responses include a descriptive message and error code:

Best Practices

When managing provider configurations:

1. Use descriptive names that identify the environment and purpose

2. Implement least privilege by configuring only necessary services and resources

3. Use allow lists rather than deny lists when possible for better security

4. Test configurations in development environments before production

Related Documentation