Salesforce Request–Response Integration Pattern

1️⃣ What It Is

The Request–Response Integration Pattern is when Salesforce initiates a call to an external system and waits for the response within the same transaction.

Think of it as:  “Salesforce knocks on the external system’s door, asks for something, waits at the door, gets the answer, and then continues processing.”

This is a synchronous, blocking integration pattern.

Salesforce acts as the client, and the external service acts as the provider.

2️⃣ When to Use It (Typical Use Cases)

Use this pattern when Salesforce must immediately receive information before proceeding.

Common examples:

🔹 Salesforce must validate data in real time (e.g., tax, address, pricing)

🔹 Real‑time credit score lookup

🔹 Real‑time inventory availability from ERP

🔹 Getting exchange rates, fraud checks, or KYC services

🔹 Payment gateway authorization Use this when Salesforce needs the response right now to continue a process or transaction.

3️⃣ Available Options in Salesforce

🔹 1. Apex Callouts (HTTP / REST / SOAP)

• Most common method
• Supports GET/POST/PUT/DELETE
• Full control over headers, payloads, handling

🔹 2. Named Credentials

• Secure storage of external URLs + credentials
• Simplifies auth + callout setup
• Strongly recommended for modern integrations

🔹 3. External Services (OpenAPI / API Spec‑Driven)

• Declarative method to convert external APIs into invocable actions in Flow

🔹 4. Salesforce Connect (External Objects)

• Real‑time data federation (NOT replicated)
• Great for read-only or light write operations

🔹 5. Flow HTTP Callouts (for simple scenarios)

• Low‑code callouts
• Great for admin‑friendly automations

4️⃣ Benefits

✔ Real‑time response - Salesforce gets immediate answers to continue processing.

✔ Reduced duplication - No need to store external data locally.

✔ Leverages external system logic - Rules, validation, tax engines, pricing engines, etc.

✔ Better user experience - UI can display fresh data instantly.

✔ Simple to implement - REST/SOAP callouts are straightforward for developers.

5️⃣ Best Practices

🔐 Security

• Always use Named Credentials
• OAuth 2.0 wherever possible
• Avoid hard‑coding URLs or credentials
• Validate all external responses

⚙ Performance

• Keep callout response times below 3 seconds
• Cache results where applicable
• Avoid long‑running transactions

🧱 API Design

• Use versioning in external APIs
• Return consistent JSON structures
• Provide meaningful error codes

🪵 Reliability

• Always implement retry logic on middleware, not Salesforce
• Implement circuit breakers to avoid cascading failures
• Use fallback responses where possible

📊 Monitoring

• Log request/response bodies
• Track execution times
• Monitor callout exceptions
• Integrate with Splunk, Datadog etc.

6️⃣ Key Considerations

⚠ Salesforce Limits

• Callout timeout limit: 120 seconds
• Max 100 callouts per transaction
• API governor limits

⚠ External System Availability

• If the external system is down → Salesforce transaction fails
• Consider fallback patterns or hybrid (request-response + async backup)

⚠ Error Handling

• Timeouts
• Network issues
• Invalid responses
• HTTP errors (400/500 series)
• JSON parse errors

⚠ Data Volume

• Request–response is NOT suitable for large datasets
• Use Bulk API or batch patterns instead

⚠ Transaction Control

• Callouts are not allowed after performing DML
• Use order: Callout → Process → DML

7️⃣ Sequence Diagram