Salesforce REST API Testing
Salesforce REST API testing validates synchronous JSON integrations in both directions: the inbound calls external systems make into your org through sObject, query, composite and collection resources, and the outbound callouts Apex and Flow make to external REST services through named credentials. SyntraFlow is designed to assert on authentication, status codes, response bodies and persisted records, so a REST contract is proven rather than assumed.
REST API validation is available for demonstration and proof-of-concept validation against your org and endpoints.
Two directions, one contract discipline
Most Salesforce orgs use REST in both directions. Inbound, a commerce site, mobile app or middleware flow authenticates through a connected app and calls resources such as /sobjects, /query and /composite to create and read records. Outbound, Apex code or an HTTP Callout action in Flow calls an external service — a tax engine, an address validator, a pricing service — and writes the response back to a record while the user waits.
The failures differ by direction. Inbound calls break when org metadata changes underneath the caller: a field becomes required, a validation rule is added, the integration user loses field access. Outbound callouts break when the external service changes, slows down or rejects credentials, and because they run synchronously inside a Salesforce transaction they can also break on governor limits. A REST test suite needs both perspectives.
This is the dedicated REST page. For asynchronous high-volume loads, see Salesforce Bulk API testing; for XML and WSDL-based integrations, see Salesforce SOAP API testing.
Inbound REST resources and what to validate
Each resource family has its own semantics, limits and error behavior, and each deserves its own assertions.
| Resource | What to validate | Typical defect |
|---|---|---|
| sObject create, update, delete | 201 with an ID on create, 204 on update and delete, field values on read-back | A 201 returned while a Flow later changes the value the caller relies on |
| Upsert on external ID | 201 when created, 200 when updated, 300 when the external ID matches more than one record | Duplicates created because the external ID field is not marked unique |
| SOQL query and queryMore | Row counts, nextRecordsUrl paging, relationship fields and nulls | Callers that read only the first page and silently drop records |
| Composite | Subrequest ordering, referenceId resolution between steps, allOrNone rollback | A later subrequest fails but earlier writes commit because allOrNone was false |
| sObject Collections | Per-record success and errors for up to 200 records, allOrNone behavior | A caller that checks the HTTP status only and misses failed records in the array |
| Composite graph and sObject Tree | Parent and child records created together with correct relationships | Orphaned children or partial graphs after a single node fails |
| Limits resource and headers | Remaining daily API requests reported via the limits resource and Sforce-Limit-Info | Integrations exhausting the org allocation during peak load |
Testing an inbound REST integration
SyntraFlow can be configured to run the same sequence an external caller does and assert at each layer.
Authenticate with the real OAuth flow
The test obtains a token using the flow the integration actually uses — JWT bearer, client credentials or web server — through its connected app or external client app, and confirms scopes and the run-as user are correct.
Pin the API version
Requests target the same versioned endpoint the integration uses, so behavior differences between API versions are caught before a version upgrade or retirement.
Send the request and assert the status
Create, upsert, composite or collection requests are issued with controlled payloads and the exact expected status code is asserted, not just any 2xx.
Inspect the response body
Returned IDs, success flags and error arrays with errorCode and fields are asserted, so a REQUIRED_FIELD_MISSING or FIELD_CUSTOM_VALIDATION_EXCEPTION is recognized precisely.
Read back the persisted record
A follow-up query confirms values after triggers, Flows and duplicate rules have run, proving the org holds what the caller believes it sent.
Exercise negative authentication
An expired token must return 401 with INVALID_SESSION_ID, and a user without field access must be refused, so the caller's refresh and error handling are proven.
Outbound REST callouts from Salesforce
Synchronous callouts run inside a Salesforce transaction, which gives them failure modes that inbound calls never have.
Named and external credentials
Callouts should resolve their endpoint and authentication through a named credential and external credential, with principals granted by permission set. Tests confirm the right principal is used and that a user without access is refused.
Timeouts and slow services
A callout has a configurable timeout and a cumulative limit per transaction. Tests simulate a slow response to confirm the user sees a controlled error rather than a stalled page.
Callout ordering rules
Salesforce blocks a callout after uncommitted DML in the same transaction. Tests catch the uncommitted work pending error that appears when automation is reordered.
Callouts from triggers
Triggers cannot call out synchronously, so the work moves to a Queueable or future method. Tests confirm the asynchronous callout runs and its result is written back.
Response parsing
A new, missing or retyped field in the external JSON can break deserialization. Tests replay realistic and malformed responses to prove parsing is tolerant where it should be.
Error status handling
4xx and 5xx responses from the external service must be surfaced, logged and, where appropriate, retried — never written to the record as if they were valid data.
REST limits and settings to verify
Many REST incidents are configuration or allocation problems rather than code defects, so they belong in the suite.
- The org's rolling 24-hour API request allocation, and how much of it each integration consumes at realistic volume.
- Concurrent long-running request limits, which can reject calls during peak traffic even when daily allocation remains.
- Composite subrequest and sObject Collections record limits, so callers batch correctly instead of receiving errors at scale.
- Connected app or external client app policies such as permitted users, IP relaxation and refresh token expiry.
- Named credential endpoint URLs per environment, so a sandbox never calls a production service after a refresh.
- Per-transaction callout count and cumulative timeout for flows that chain several callouts.
- Integration user object, field and record access, tested alongside integration user testing.
Why mocks are not enough
Apex unit tests cannot make real callouts, so they rely on HttpCalloutMock to return canned responses. That is the right tool for code coverage and logic, but a mock only proves the code handles the response the developer imagined. It cannot detect that the real service changed a field name, started returning a 429 under load, or that the named credential in a refreshed sandbox points at the wrong host.
SyntraFlow is designed to complement unit tests by exercising callouts against real or realistic endpoints in a test environment and asserting on the record outcome in Salesforce. Where the callout feeds a business process — an address check during account creation, a price lookup during quoting — the same scenario can continue into the process itself, drawing on Salesforce test automation for any UI steps.
Deliberate failure cases, such as a timed-out callout or a 503 from the external service, are covered in more depth under integration error and recovery testing.
Status codes worth asserting explicitly
A precise status assertion catches misleading responses that a generic success check misses.
| Status | Meaning in Salesforce REST | What the test should confirm |
|---|---|---|
| 200 and 201 | Request succeeded or record created | The body and read-back values match, not just the code |
| 204 | Update or delete succeeded with no body | The caller does not expect a body and the change persisted |
| 300 | Upsert external ID matched multiple records | The integration treats this as an error, not a success |
| 400 | Malformed request or failed validation | The errorCode and fields identify the exact cause |
| 401 | Session expired or invalid | The caller refreshes its token and retries once |
| 403 | Insufficient access or request limit exceeded | Access errors and REQUEST_LIMIT_EXCEEDED are handled differently |
| 404 | Resource or record not found | Deleted or merged records are handled without data loss |
Related pages
Salesforce API Testing
The parent hub comparing REST, SOAP and Bulk API validation.
Salesforce Integration Testing
The wider integration discipline across middleware and connected systems.
Salesforce Bulk API Testing
Asynchronous high-volume jobs where REST is the wrong tool.
Salesforce SOAP API Testing
WSDL-based integrations with typed XML contracts.
Integration Error and Recovery Testing
Timeouts, retries and idempotency for failed calls and callouts.
Integration User Testing
Confirm the API user has exactly the access each call needs.
REST API Testing testing FAQs
What is Salesforce REST API testing?
Salesforce REST API testing validates JSON integrations over HTTP in both directions. Inbound, it checks calls into sObject, query, composite and collection resources for correct status codes, response bodies and persisted records. Outbound, it checks Apex and Flow callouts to external REST services for authentication, timeouts, parsing and error handling.
Why test the persisted record if the API returned 201?
A 201 confirms the insert was accepted, but triggers, record-triggered Flows and other automation can still change field values in the same or later transactions. A follow-up query proves the record holds the values the caller expects, which is what downstream systems will actually read.
What is the difference between composite and sObject Collections?
Composite runs a series of different subrequests in one call and lets later steps reference earlier results by referenceId. sObject Collections creates, updates or deletes up to 200 records of possibly different types in one call. Both support allOrNone, so tests should confirm whether a single failure rolls back the whole request or only fails that record.
How do you test outbound callouts that use named credentials?
Run the callout in a test environment where the named credential and external credential point at a controlled or sandbox endpoint, then assert on the record outcome. Include negative cases such as a user without the external credential principal, an expired token, a slow response and a 5xx error, and confirm each is handled cleanly.
Do API version changes affect REST integrations?
Yes. Each request targets a versioned endpoint, and behavior or available fields can differ between versions. Salesforce also retires old API versions over time, so integrations pinned to an old version should be tested against a current version before the retirement date.
Does SyntraFlow replace Postman or HttpCalloutMock?
No. Postman is useful for exploration and HttpCalloutMock is required for Apex unit tests. SyntraFlow is designed to run REST calls and callouts as repeatable steps inside end-to-end scenarios and to confirm the outcome in Salesforce and the connected system. These capabilities are available for demonstration and proof-of-concept validation.
Prove every REST call in both directions
See how SyntraFlow is designed to validate inbound REST requests and outbound callouts against your org and endpoints.