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: |
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 | 25 MB | |
Maximum size of the response from the REST endpoint | 25 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
|
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
|
Low CO2 |
Dallas |
us-south1
|
|
Montréal |
northamerica-northeast1
|
|
Toronto |
northamerica-northeast2
|
|
São Paulo |
southamerica-east1
|
Low CO2 |
Santiago |
southamerica-west1
|
Low CO2 |
Europe
Region description | Region name | Details |
---|---|---|
Belgium |
europe-west1
|
Low CO2 |
London |
europe-west2
|
|
Frankfurt |
europe-west3
|
|
Netherlands |
europe-west4
|
|
Zurich |
europe-west6
|
Low CO2 |
Milan |
europe-west8
|
|
Paris |
europe-west9
|
Low CO2 |
Berlin |
europe-west10
|
|
Turin |
europe-west12
|
|
Finland |
europe-north1
|
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 |