Integration Patterns and APIs
Integration Patterns and APIs
This domain tests integration style selection, API choice, authentication, and - most heavily - failure handling and limit management. The exam rewards candidates who pick the pattern from the requirement rather than from familiarity.
Styles and when they apply
- Request-reply (synchronous): user-facing needs where the user waits. Every callout counts against transaction time; the maximum callout timeout is 120 seconds.
- Fire-and-forget: non-critical notifications where loss is tolerable.
- Batch data synchronization: scheduled volume movement.
- Publish-subscribe: decoupled event distribution to many consumers.
- Remote process invocation: executing logic in another system.
- Data virtualization: Salesforce Connect for data that must not be copied.
API selection
REST for single-record CRUD from web or mobile. SOAP where WS-Security or heavy enterprise contracts demand it. Bulk API 2.0 for thousands to millions of records - asynchronous, job-based, far cheaper against API limits than REST loops. Composite API for multi-object operations in one round trip. GraphQL for shaped reads. Streaming covers Platform Events (custom schema), Change Data Capture (record changes), and the gRPC-based Pub/Sub API. Metadata and Tooling APIs serve DevOps, not business integration.
Reliability rules
Idempotency via external IDs and upsert. Retry with exponential backoff, plus a dead-letter store and replay procedure. Do not assume global ordering of platform events across partitions. API limits are a 24-hour rolling allocation, so budget per integration and monitor consumption. Named Credentials and External Credentials hold secrets and support per-user or per-org authentication. For server-to-server use the OAuth JWT bearer flow; the username-password flow is deprecated and should be avoided.
Worked example
An ERP sends 500,000 nightly product updates and must also push order status in near real time. Use Bulk API 2.0 for products: one job instead of 500,000 REST calls. For status, publish Platform Events or enable Change Data Capture, consumed by the middleware through Pub/Sub API - this removes polling. If the ERP cannot publish events, the middleware polls on a short interval and publishes instead. Retries key on the order's external ID so duplicate deliveries are harmless.
Traps that cost marks
REST loops for six-figure volumes. Polling where events fit. Assuming platform event ordering. Secrets stored in custom settings. Callouts inside record loops. Treating CDC as full replication - events are retained 72 hours. Ignoring the 24-hour rolling API limit.
Key points
- Bulk API 2.0 for volume; REST for single records.
- Platform Events and CDC are 72-hour-retention streams, not a database.
- Idempotency via external IDs makes retries safe.
- Named Credentials and External Credentials replace stored secrets.
- Always design a dead-letter path and replay procedure.