Apigee Integration quotas and limits

This section describes Apigee Integration quotas and limits you should consider as you design, build, and manage your integrations. The Apigee Integration feature is designed for stability and performance when configured for use cases within these quotas and limits.

A quota restricts how much of a particular shared Google Cloud resource your Cloud project can use, including hardware, software, and network components.

Quotas are part of a system that does the following:

  • Monitors your use or consumption of Google Cloud products and services.
  • Restricts your consumption of those resources for reasons including ensuring fairness and reducing spikes in usage.
  • Maintains configurations that automatically enforce prescribed restrictions.
  • Provides a means to make or request changes to the quota.

When a quota is exceeded, in most cases, the system immediately blocks access to the relevant Google resource, and the task that you're trying to perform fails. In most cases, quotas apply to each Cloud project and are shared across all applications and IP addresses that use that Cloud project.

There are also limits on Apigee Integration resources. These limits are unrelated to the quota system. Limits cannot be changed unless otherwise stated.

Resource quotas

The following quotas apply to Apigee Integration resources per Google Cloud project:
Resource Quota Value Can be increased
Integration execution Maximum concurrent executions per project 10 No
Maximum concurrent executions per integration 10 No
Maximum task executions per day (Subscription payment model) 500 No
Number of integration execution requests per minute 24000 No
Integration Connectors Maximum number of connections per region per project 50 Yes
Number of read connection schema requests per minute 12000 No
Number of read connection requests per minute 12000 No
Number of read region requests per minute 12000 No
Integration execution logs and monitoring Number of read executions requests per minute 12000 No
Integrations page

(This page lists all the available integrations in your project)

Number of read integration requests per minute 12000 No
Integration designer page

(This page loads a whole integration including all the integration versions and configured task entities)

Number of read task entity requests per minute 12000 No
Number of read integration version requests per minute 12000 No
Number of write integration version requests per minute 12000 No
Salesforce trigger Number of read Salesforce channel requests per minute 12000 No
Number of write Salesforce channel requests per minute 12000 No
Number of read Salesforce instance requests per minute 12000 No
Number of write Salesforce instance requests per minute 12000 No

Usage limits

Apigee Integration enforces the following usage limits. Your are responsible for tracking and ensuring that the values stay within the prescribed limits. Exceeding the limits might lead to reduced throughput, task failures, and increased latencies when running the integration.
Resource Limit Value
Applicable to the entire Apigee Integration Maximum characters in the integration name 64 characters
Maximum cumulative size of all the integration data (including input and output variables) 25 MB
Maximum cumulative size of all the integration data (including input and output variables) sent and received from connections 8 MB

Timeout for synchronous (SYNC) integration executions.

The timeout duration includes any external system calls or sub-integration tasks of the integration during its execution. Examples of external system calls include, calling external endpoints, calling Salesforce using connectors, and calling Google Cloud functions.

2 minutes

Timeout for asynchronous (ASYNC) integration executions.

If your sub-integration takes longer than 2 minutes to run, consider executing your integration in ASYNC mode.

10 minutes

Maximum time till which an older version of the integration can run after publishing the new version (system consistency).

This is because Apigee Integration is a distributed system that provides eventual consistency. It uses caches throughout the system that may take time to clear and refresh.

10 minutes

Maximum number of tasks in an integration.

If there is a need for more tasks, it is recommended that you split your integration into multiple integrations.

100
Maximum versions allowed for an integration 100
API trigger Maximum characters for TRIGGER_NAME in Trigger ID.

Trigger ID format: api_trigger/TRIGGER_NAME

64 characters
Apps Script task Maximum active deployments for an Apps Script 50
Queries per second (QPS) for API executables 5000 per minute
Queries per second (QPS) for Webapp deployments 5000 per minute
Latency for API executables 1.5 seconds
Latency for Webapp 2.5 seconds
Maximum cumulative size of all the integration variables in an Apps Script 15 MB
Call REST Endpoint task Maximum number of concurrent REST calls 10000
Maximum size of the request to the REST endpoint 20 MB
Maximum size of the response from the REST endpoint 20 MB
Call Integration task Maximum number of sub-integrations that can run from the main integration 10000
Connectors task Maximum size of the response from the connector 20 MB
While Loop and For Each Loop tasks Maximum cumulative size of data processed 20 MB
Maximum number of iterations 8000
For Each Parallel task Maximum cumulative size of data processed 20 MB
Maximum number of parallel executions 10000
Datamapping task Maximum size of an array data type variable 100000 elements
Maximum size of a JSON data type variable 20 MB
Maximum size of a string data type variable 20 MB
Maximum size of a JSON data type variable 20 MB
Data Transformer Script task Maximum memory available for script evaluation 300 MB

Data processing limits

We don't recommend using integrations in the following scenarios:

  • Integration requires movement of bulk data or focus on extract, transform, and load (ETL) processes.
  • Cumulative size of all the integration data is greater than 10 MB during execution.

    When calculating the cumulative data size, add the size of all types of data such as input variables, output variables, and other intermediate task variables.

Supported regions

Apigee Integration supports data plane and runtime regionalization. During the integration creation process, users can select the specific region for data and execution to reside.

The following table lists the regions where Apigee Integration is available.

Americas

Region description Region name Details
Oregon us-west1 leaf icon Low CO2
Los Angeles us-west2
Salt Lake City us-west3
Las Vegas us-west4
South Carolina us-east1
Northern Virginia us-east4
Columbus us-east5
Iowa us-central1 leaf icon Low CO2
Dallas us-south1
Montréal northamerica-northeast1
Toronto northamerica-northeast2
São Paulo southamerica-east1 leaf icon Low CO2
Santiago southamerica-west1 leaf icon Low CO2

Europe

Region description Region name Details
Belgium europe-west1 leaf icon Low CO2
London europe-west2
Frankfurt europe-west3
Netherlands europe-west4
Zurich europe-west6 leaf icon Low CO2
Paris europe-west9 leaf icon Low CO2
Berlin europe-west10
Turin europe-west12
Finland europe-north1 leaf icon Low CO2
Warsaw europe-central2
Madrid europe-southwest1

Asia-Pacific

Region description Region name
Taiwan asia-east1
Hong Kong asia-east2
Mumbai asia-south1
Delhi asia-south2
Tokyo asia-northeast1
Osaka asia-northeast2
Seoul asia-northeast3
Singapore asia-southeast1
Jakarta asia-southeast2
Sydney australia-southeast1
Melbourne australia-southeast2

Middle East

Region description Region name
Doha me-central1
Dammam me-central2
Tel Aviv me-west1