Salesforce–EHR integration discussions often mix four different limits into one number: the Salesforce org's daily incoming API allocation, Salesforce's per-transaction governor and callout limits, Platform Event delivery allocations, and the EHR vendor's own rate limits. A reliable design identifies each one.
This distinction matters in GAT's production work. The Opus Behavioral Health EHR admission pipeline makes approximately 12 outbound EHR callouts for a typical new admission. Those calls matter to the Salesforce transaction and the vendor API budget; they should not be presented as 12 incoming Salesforce API requests. The AdvancedMD architecture receives webhooks into Salesforce and uses a different capacity shape.
Planning worksheet
Model two API budgets, not one
Requests into Salesforce draw from the org's daily API allocation. Callouts from Salesforce to the EHR draw from a different set of Salesforce transaction limits and the EHR vendor's quota.
Start with the official Salesforce allocation
Salesforce says the daily API request limit covers REST, SOAP, Bulk, and Connect API requests over a rolling 24-hour period. Paid editions such as Enterprise begin at 100,000 requests and increase with the licenses provisioned to the org. It is a soft limit until a system-protection threshold is enforced, at which point calls can receive REQUEST_LIMIT_EXCEEDED. See Salesforce API limits and monitoring.
Do not design steady-state production volume around the soft overage. Check the actual org in Setup, the API response Limit Info header, or the REST /limits resource. Add notifications before the integration launches, not after a request storm.
Which actions count against which budget?
| Action | Salesforce daily API allocation | Other capacity to model |
|---|---|---|
| Vendor webhook calls Salesforce REST/Apex REST | Yes, as an incoming API request | Webhook burst and Salesforce transaction limits |
| External service queries or writes Salesforce | Yes | Concurrency, payload, query, and client retry behavior |
| Salesforce Apex calls the EHR | Not as an incoming Salesforce API request | Apex callout limits, transaction time, and vendor quota |
| External client publishes a Platform Event through an API | Yes | Platform Event publish and delivery allocations |
| Flow or Apex works inside Salesforce | Not merely because it is internal work | Governor, automation, async, and event limits still apply |
| Admin changes a Custom Metadata mapping in Setup | Not an ongoing external integration request | Release governance and validation of the changed mapping |
Composite reduces round trips; it does not remove design work
Salesforce's REST Composite resource can execute up to 25 subrequests in one call, and the series counts as one call toward API limits. Up to five subrequests can be query or sObject collection operations. See the Salesforce Composite API documentation.
That can materially reduce network round trips. It also creates a larger failure envelope. Decide whether dependent operations should roll back together, how partial results are interpreted, and whether a retry is safe. Batching a bad identity strategy only creates duplicates faster.
Platform Events change timing and failure exposure
A webhook handler that validates and publishes an event does less synchronous work than a handler that writes several heavily automated objects before responding. Subscribers can process the business work asynchronously, and replay gives consumers a recovery tool. That is why GAT uses events as a buffer in the AdvancedMD integration.
Platform Events are not a universal queue or a license-free replacement for middleware. Salesforce documents event publish and notification allocations, and API-based publishing still uses standard API capacity. Middleware can be warranted when multiple systems consume the same events, transformation is substantial, or operational service-level controls exceed the native pattern. See Salesforce integration patterns.
Six patterns preserve headroom and trust
Push, do not poll
Failure mode
A scheduled job asks Salesforce whether anything changed—even when nothing did.
Design decision
Use a webhook, Change Data Capture, or another event signal when the source can publish a reliable change.
Combine related work
Failure mode
A client creates one request for every record and relationship in the same business action.
Design decision
Use Composite or collection resources when transactional and error-handling requirements fit.
Cache stable facts
Failure mode
Every admission re-queries mappings, facility IDs, programs, or other reference data that rarely changes.
Design decision
Cache stable external facts with an explicit refresh and invalidation policy.
Make retries idempotent
Failure mode
A timeout is retried as a new create, producing duplicate patients or episodes.
Design decision
Use deterministic external IDs, writeback, safe re-entry, and a reconciliation path.
Reserve for failure
Failure mode
The capacity model uses average traffic and has no room for bursts, replay, or a vendor outage.
Design decision
Budget normal load, burst load, retries, backfill, and the other integrations sharing the org.
Monitor both sides
Failure mode
Salesforce headroom looks healthy while the EHR throttles, rejects, or changes an endpoint.
Design decision
Track Salesforce consumption, vendor quota, latency, errors, retry age, and reconciliation backlog separately.
Configuration changes the ownership cost
GAT's AdvancedMD field mappings live in Custom Metadata. An admin can update a mapping fact without rewriting the Apex behavior or deploying a new hardcoded map. The Opus build keeps environment routing and document allow-lists in protected configuration. This does not make the integration API-free. It makes ordinary schema and environment changes less dependent on a developer.
The production capacity checklist
- Measure the org's current 24-hour and 30-day API usage before adding a workload.
- Separate incoming Salesforce calls, outbound EHR callouts, event allocations, Bulk jobs, and concurrency.
- Model average, peak, retry, replay, reconciliation, and backfill traffic.
- Confirm the EHR's writable endpoints, rate limits, sandbox, and support escalation.
- Define external IDs, idempotency, partial failure, and safe re-entry.
- Add alerts for Salesforce headroom, vendor throttling, error age, and reconciliation backlog.
- Assign a human owner and document what happens when an endpoint or field changes.
The Behavioral Health Integration Fit Check starts with the systems and handoff. The cost guide shows how the capacity and ownership decisions affect scope.
Frequently asked questions
What is Salesforce's daily API limit?
Salesforce says paid org editions such as Enterprise begin with 100,000 API requests over a rolling 24-hour period and increase with provisioned licenses. Confirm the specific org's maximum and remaining allocation in Setup, response headers, or the REST Limits resource.
Do Apex callouts from Salesforce to an EHR consume the Salesforce daily API request limit?
They are not incoming requests to Salesforce and therefore are not counted the same way against the org's daily API request entitlement. They are still governed by Salesforce transaction and callout limits and by the EHR vendor's quotas, so they require a separate capacity model.
Do Platform Events eliminate API use?
No. Platform Events support asynchronous decoupling and replay, but publishing or consuming them through Salesforce APIs can use standard API allocations and event-delivery allocations. Events change the failure and timing model; they do not make traffic free.
How can an integration reduce Salesforce API consumption?
Avoid unnecessary polling, consolidate related work with Composite or collection resources where appropriate, cache stable reference data, request only needed fields, use event-driven notifications, and design retries so the same failure does not create a request storm.
When does middleware make sense?
Middleware earns its cost when several systems consume the same events, transformations are substantial, queuing and service-level controls exceed the native pattern, or operations needs one integration control plane. A point-to-point workflow can often remain native when its volume, ownership, and failure model are simple enough.