# How to govern API limits when integrating multiple Salesforce clouds

Give each integration a budget of calls. Prefer bulk and events to polling. When the platform tells you to slow down, slow down. The cap depends on edition and licences.

**Published:** 2026-03-27
**Canonical:** https://synconai.com/govern-api-limits-salesforce
**Author:** SynconAI Architecture Team

## In short

Govern API use by giving each integration a budget of calls, preferring bulk reads and events over polling, and backing off when the platform refuses a call. The allowance differs by edition and by licences. Look up the current figure for the edition you pay for. A daily cap printed from memory will be wrong for someone, and several integrations will hit it together.

## Sources

- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs.
- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > Connect data using zero copy data federation.

## What to take away

- Each integration has a budget, an owner, and a pattern: bulk, event, or poll.
- The allowance is edition-specific. Look it up. Do not reuse a number from an old slide.
- Polling and retries without backoff are how several integrations fail in the same hour.
- Zero-copy federation avoids a stream of single-record copies. It does not end API use.

## The guide

At the top of the hour the org stops answering. Three integrations asked whether anything had changed, on a one-minute timer, whether or not it had. Each of them, on the refusal, tried again immediately. The integration that was inside its means is refused with the rest. A dashboard someone added last month, which polls so a tile can look live, was never on the register. The number in the design was copied from a slide two releases old, for a different edition. Nobody can say what the allowance actually is today. They can say the platform said no.

API trouble in a multi-cloud org is rarely one bad call. It is polling, retries without a wait, and no budget per integration. The platform then refuses calls for everyone, including the integration that was behaving. Governance is a register: who may call, how, and what they do when the answer is no.

## A budget you looked up

Write, per integration, how many calls it may make and who is told when it crosses that line. The number comes from the current limits for your edition and your licences, read this quarter, with the date of the reading on the row. Editions differ. Licences differ. A figure copied from another customer's org, or from a post that is two releases old, is how you plan a failure. This guide will not print a daily cap. There is no single cap that is true for every org, and inventing one would be worse than leaving the cell blank until someone opens the current page. A blank is a task. A wrong number is a design.

Split the budget by integration, not as one pool everyone shares until it is gone. A shared pool means the noisiest caller spends it, and the caller that was careful is the one that fails in front of a user. The register names the share. When a new integration is proposed, it gets a share by taking from somewhere, or by a decision that the total still fits. "We will watch it" is not a share. Watching starts after you have said what too much looks like.

[Data 360 help](https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5) makes a related point inside its own product: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." Keep that sentence on Data 360. It says some of those features have limits, and that many of them can be adjusted. An adjustment is a planned commercial and technical change, with a date and a person who asks for it before you need it. It is not what you rely on during an incident instead of backing off. Core API allowances are still the edition you bought. Read them. Put the date you read them on the register. Do not treat a Data 360 sentence as the ceiling for every cloud you call.

Who is told matters as much as the number. The owner of the integration, named, gets the warning before the refusal, at a threshold you chose while things were quiet. A channel that pages the whole company at the first soft warning will be muted. A channel that pages nobody will be discovered in the outage. One person, one threshold, written on the row.

## Polling spends the allowance on purpose

A job that asks whether anything changed, on a short timer, spends calls whether or not anything changed. That pattern is the usual way a quiet integration becomes the one that takes the org down at the top of the hour. The timer feels safe because each call is small. The hour is the sum. Prefer a bulk read on a schedule the business actually needs: nightly, or hourly, or when a person asks, not because a default job runs every minute. Prefer platform events and change notifications where you already have them, so you spend a call when something happened. Events have their own allowances. Look those up with the rest, on the same date, and put them on the register. Preferring them is not a claim that they are free.

"Just the changed rows" every minute is still a poll if you ask every minute whether rows changed. The phrase describes the payload. It does not describe the cost. If the business needs the change within a day, a daily bulk read is the design. If the business needs it within a minute, say so, cost the pattern against the allowance you looked up, and do not discover the cost at the top of the hour. A requirement nobody can tie to a decision is not a requirement for a one-minute timer. It is a habit copied from the last integration.

A callout on a record save is the same family of problem, from the other side. The save now waits on a system you do not control, and every save spends the allowance. That work belongs off the save, which is the diagram in [an architecture with one owner per object](/scalable-salesforce-architecture). An integration that hides inside a flow will not appear on the register unless the owner of the object and the owner of the integration are required to write it there. Make them.

:::note
Events are not free. Bulk reads are not free. A one-minute poll is the expensive version of a question you could have asked once. Look up the allowance for the pattern you picked. Do not assume the quieter pattern has no ceiling.
:::

## Zero copy is not the end of calling

Salesforce says: "Connect data using zero copy data federation." Zero copy is a way to read data in place instead of copying the estate through a stream of single-record calls. Use it where it fits the question you are asking: wide data, a source that can carry the query, a consumer that can tolerate the latency. It does not switch off API use, and it does not excuse an unbudgeted subscriber that still polls beside it. The register lists the federation and the calls you still make. A design review that says "zero copy, so limits do not apply" has skipped the row. Write the row. If the federation still issues queries, those queries have an owner and a pattern.

Do not use a federation as a way to avoid deciding the budget. The question is still how often you ask, how wide the ask is, and what you do when the source is slow or refuses. A live read during a conversation that fails because the source is busy is a worse failure than a copy that is an hour old, for many service paths. Choose per integration. Record the choice. The slogan is not the choice.

## Back off when the platform says no

When a call fails because you are over the allowance, an immediate retry from every integration makes the next interval worse. Back off. Queue the work. Let the integration that is over budget wait, and let the ones inside budget continue. A shared retry storm is the second outage, and it is the one you caused after the first refusal. The wait has to be real: longer than the next tick of the timer, and not the same instant for every caller, or they will meet again together. Write the wait on the register so a new integration does not arrive with "retry immediately" as its error handling.

Know which failures are the allowance and which are something else. A refusal for limits is a signal to slow down. A refusal because the payload is wrong is a defect to fix, and retrying it will spend the allowance on a call that cannot succeed. The register says what this integration does on each. "Retry three times" as a universal handler is how a bad payload and a limit refusal look the same in the log, and how both get worse.

A new dashboard that polls is an integration. A new cloud that syncs changed rows every minute, without a budget, is an integration. A sandbox job pointed at production "just to test" is an integration. Add them to the register before they go live: name, pattern, budget, owner, and the date the edition's limits were last checked. Review the page when you add a cloud or a subscriber, not at the incident. The failure mode is boring and repeatable. Polling, retries without backoff, and no budget per integration. Write the register so that mode has to get past a person.

| Row | What you write | A gap |
| --- | --- | --- |
| Name | The integration, including dashboards that poll | "Various" or a platform with no owner |
| Pattern | Bulk, event, or poll, and how often | "Near real time" with no interval |
| Budget | A share of the allowance you looked up, with the date | A number from another org or an old slide |
| On refusal | Back off and queue, or fix a bad payload | Retry immediately, from every caller |
| Owner | A person told before the line is crossed | A shared inbox nobody reads |

:::warn
Do not print a daily cap in the design until you have read the current limits for this edition and these licences. A number from memory will be wrong for someone. Several integrations will hit the real ceiling together, and the careful one will fail with them.
:::

Count a quiet hour before you count an incident. For one integration, write how many calls it made when nothing in the business was happening, and how many it made when the work it exists for was happening. If the quiet hour is most of the budget, the pattern is the defect, and a raised allowance will be spent on the same quiet hour. Show that comparison to the owner before you talk about buying more. The comparison is the design review. The invoice is what you do after the pattern is one you mean to keep.

The careful integration needs a way to keep working when another caller is over budget. A single shared pool, with no shares and a retry from everyone, will not give it that. Queue the caller that crossed its line. Leave the others running. If you cannot tell them apart in the log, the register is missing the name, and the next outage will look like one failure when it was three patterns meeting at the top of the hour.

Cheap, before the next subscriber: the register, the date you read the allowance, a budget per caller, and a backoff that is longer than the timer.

Expensive, after the top of the hour has already failed: explaining to every team why their integration, including the one inside its means, was refused, and unwinding a retry storm you scheduled. The register is how that hour does not repeat. Leave the cell blank until someone has opened the current page. Then write the figure, the date, and the owner. Not a number from a slide.

## Questions

### Which daily cap should we print in the design?

None, until you have read the current limits for your edition and licences, and written the date you read them. Allowances differ by edition and by what you bought. A number from another org, an old post, or a slide will be wrong for someone. Several integrations can hit the real ceiling together, including the one that was inside its means. Leave the cell blank rather than invent a figure. This guide does not print a daily cap.

### Why is polling the usual way this fails?

A short timer asks whether anything changed and spends the allowance either way. The hour is the sum of calls that felt small. Prefer a bulk read on a schedule the business needs, or events where you already have them, and still put a budget on those calls. Events have allowances too. "Just the changed rows" every minute is still a poll. If nobody can tie the minute to a decision, the timer is a habit, not a requirement.

### Does zero copy remove API use?

Salesforce says to connect data using zero copy data federation. That reads in place instead of copying the estate through a stream of single-record calls. It does not mean the rest of your integrations have stopped calling, and it does not mean the federation itself is outside the register. List the federation and the calls you still make. A review that says limits no longer apply has skipped the row.

### What do we do when a call is refused for limits?

Back off and queue the work. The wait has to be longer than the timer, and not the same instant for every caller, or they meet again together. Immediate retries from every integration make the next interval worse. A bad payload is a defect, not a limit refusal, and retrying it spends the allowance on a call that cannot succeed. A Data 360 note that many of its limits can be adjusted is a planned change, not an incident plan.

### What belongs on the register?

Integration name, pattern (bulk, event, or poll) and how often, a budget taken from the allowance you looked up, an owner who is told before the line is crossed, and the date someone last checked the edition limits. A dashboard that polls is an integration. A sandbox job pointed at production is an integration. Add both before they go live. A shared pool with no shares is not a register.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Integration and architecture (https://synconai.com/salesforce-integration-services).