Salesforce API Testing: How I Validate REST, SOAP, and Bulk APIs in Real Projects

Which Salesforce APIs Do You Actually Test?

Salesforce exposes 6 API families for testing: REST, SOAP, Bulk, Streaming, Tooling, and the Agentforce Testing API. Each family serves a different integration pattern. Testing each one means asserting on different things.

The 6 families at a glance:

• REST API: REST handles the majority of modern integration work through JSON over HTTP.

• SOAP API: SOAP serves enterprise-grade, XML-based integrations against a WSDL contract.

• Bulk API: Bulk moves large record volumes asynchronously through submitted jobs.

• Streaming API: Streaming pushes platform events and change notifications to subscribers.

• Tooling API: Tooling exposes metadata and development objects for org automation.

• Agentforce Testing API: The newest family programmatically evaluates AI agents in batches.

Treating them as one "Salesforce API" is the first mistake I correct in project kickoffs. What "testing" means changes per family, and the differences matter in practice.

REST API

REST is where web apps, mobile backends, and middleware call Salesforce for record CRUD and SOQL queries. Testing REST means asserting on status codes, response bodies, and stored data accuracy.

In my client work, REST carries 80%+ of the actual testing volume. Start here.

SOAP API

SOAP still runs the legacy enterprise middleware that will not migrate this decade. The contract lives in a WSDL file, so testing validates each operation against that contract.

Bulk API

Bulk testing is a different discipline from REST testing. You assert on job state polling, batch completion, and the record-level error files. Bulk comes second in testing volume on any engagement involving data migration.

Streaming API

Streaming tests verify that the right events fire on the right record changes. They confirm subscribers survive reconnects without dropping notifications.

Tooling API

Tooling matters to QA teams mostly when validating deployment-related automation. It reads and writes metadata rather than business records.

Agentforce Testing API

Agentforce Testing is new enough that I give it a full section at the end of this guide. The short version: it adds a test surface, not a replacement.

None of these APIs answers a single request without authentication. That setup comes before any test runs.

How Do You Authenticate Before Testing Salesforce APIs?

Authenticating before testing requires a Connected App plus one of 2 OAuth flows: web server or client credentials. The flow choice depends on whether a human sits at the keyboard during the run. Picking the wrong one costs teams days of confused debugging.

⚠️ Common Pitfall: Older tutorials authenticate with the username-password flow, concatenating the password and security token. Salesforce treats that flow as legacy and blocks it by default in newer orgs. Test suites copied from those tutorials fail at the token step with no obvious cause. Build new suites on the client credentials flow instead.

The token request itself is one call:

curl -X POST https://login.salesforce.com/services/oauth2/token \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

A successful response carries 2 values your tests reuse everywhere:

• access_token: The token fills the Authorization header on every request.

• instance_url: The URL builds every endpoint your tests call.

Store both as variables in whatever tool you test with.

Token expiry deserves one habit. Fetch a fresh token at the start of every automated run instead of caching one. In our QA engagements, expired cached tokens cause more false failures than any actual API defect. A fresh token per run removes that entire failure class.

With a token in hand, Postman is where most Salesforce API testing starts.

How to Test Salesforce APIs Using Postman

To test Salesforce APIs using Postman, fork the official Salesforce Platform APIs collection, configure OAuth 2.0, and run your first request. The official collection ships hundreds of pre-built requests, so nobody types endpoints by hand.

The 5 steps from zero to a passing assertion:

1. Choose the Postman desktop app.

2. Fork the official collection.

3. Authorize at the collection level.

4. Set the instance variable and send the first request.

5. Turn the check into a test.

Each step has one decision worth understanding before you click through it.

Step 1: Choose the Postman desktop app. The web version requires allowlisting Postman's domains through Cross-Origin Resource Sharing (CORS) settings in Salesforce Setup. The desktop app skips that configuration entirely. I default every team to desktop for this reason alone.

Step 2: Fork the official collection. Search the Postman public registry for "Salesforce Platform APIs" and fork the collection into your workspace. Forking keeps you connected to Salesforce's updates while giving you an editable copy.

Step 3: Authorize at the collection level. Open the forked collection's Authorization tab and set the type to OAuth 2.0. Complete Get New Access Token with your Connected App credentials. Configure this once on the parent folder. Every request underneath inherits the token.

Step 4: Set the instance variable and send the first request. Copy the instance_url from your token response into the collection's _endpoint variable. Open REST → SObject → SObject Describe, replace the object placeholder with Account, and hit Send. A working setup returns HTTP 200 with the full Account metadata as JSON.

Step 5: Turn the check into a test. A 200 response proves connectivity, not correctness. Assertions prove correctness. Paste this into the request's Tests tab:

pm.test("Status is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response under 2 seconds", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

pm.test("Describe returns the Account object", function () {
    const body = pm.response.json();
    pm.expect(body.name).to.eql("Account");
    pm.expect(body.fields).to.be.an("array").that.is.not.empty;
});

Assertion depth is what separated our work on the DropCar engagement from the status-code checking it replaced. DropCar's platform moved booking and payment data between interdependent systems, and we validated those backend APIs in Postman.

Status codes alone passed while a payment field mapped to the wrong record type. Field-level assertions caught it.

That engagement closed at 90% feature coverage and an 80%+ defect reduction. Field-level assertions did a disproportionate share of that work. The platform was not Salesforce. The lesson transfers to every Salesforce REST endpoint unchanged: assert on the data, not the status.

One more step turns the collection into a regression suite. Newman, Postman's command-line runner, executes the whole collection headless:

newman run salesforce-apis.postman_collection.json \
  -e sandbox.postman_environment.json \
  --reporters cli,junit --reporter-junit-export

Drop that command into a pipeline step and the collection becomes a nightly gate. The JUnit export feeds whichever reporter your team runs. My bias declared: I build TestReport.io, and it reads that output natively.

For 91mobiles, wiring API suites into the pipeline this way resolved 100% of their CI/CD timeouts. Execution time dropped by 50%+. A collection someone runs manually is a tool. A collection the pipeline runs is a quality gate. Teams that want the gate built rather than described bring in our automation testing service.

Postman covers structured, repeatable testing. Quick one-off checks call for something lighter.

How to Test Salesforce REST APIs in Workbench

To test Salesforce REST APIs in Workbench, log in with your existing session, open the REST Explorer, and execute requests against your org. Workbench needs no Connected App and no OAuth configuration, because it rides your active Salesforce session. Setup time is zero, which is exactly its job.

The 5 steps:

1. Open workbench.developerforce.com, pick your environment (production or sandbox), and log in with your Salesforce credentials.

2. Navigate to utilities → REST Explorer.

3. Execute a GET on /services/data/v64.0/sobjects/Account/describe and read the raw JSON response in the browser.

4. Run a SOQL query through /services/data/v64.0/query?q=SELECT+Id,Name+FROM+Account+LIMIT+5 to verify data access.

5. Switch the method to POST, target /services/data/v64.0/sobjects/Account, and submit a JSON body to confirm write access.

Workbench earns a permanent place in my toolkit for one scenario. Verifying a fix in a client sandbox takes under a minute. A developer says the endpoint is fixed. I confirm it in Workbench before the automation suite runs, and the feedback loop stays tight.

The honest boundary: Workbench holds no assertions, no test history, and no automation path. Exploration lives in Workbench. Regression lives in Postman or code.

Speaking of code, some teams skip GUI tools entirely.

How Do You Script Salesforce API Tests in Python?

Scripting Salesforce API tests in Python takes one requests-based script covering authentication, a write, read-back validation, a negative test, and cleanup. The 5-part structure is my minimum bar for calling something an API test rather than an API demo.

The 5 parts in order:

1. Authenticate with the client credentials flow.

2. Create a record and assert the 201.

3. Query the record back and assert the stored values.

4. Send a bad payload and assert the specific rejection.

5. Delete the record and assert the cleanup.

The script below runs as written against any org with a client-credentials Connected App:

import requests
import sys

AUTH_URL = "https://login.salesforce.com/services/oauth2/token"
CLIENT_ID = "YOUR_CLIENT_ID"
CLIENT_SECRET = "YOUR_CLIENT_SECRET"
API = "/services/data/v64.0"

def get_session():
    resp = requests.post(AUTH_URL, data={
        "grant_type": "client_credentials",
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
    })
    assert resp.status_code == 200, f"Auth failed: {resp.text}"
    body = resp.json()
    headers = {"Authorization": f"Bearer {body['access_token']}",
               "Content-Type": "application/json"}
    return body["instance_url"], headers

def run_tests():
    base, headers = get_session()

    # 1. Positive test: create an Account, expect 201
    payload = {"Name": "PerfectQA API Test Account", "Industry": "Technology"}
    create = requests.post(f"{base}{API}/sobjects/Account",
                           json=payload, headers=headers)
    assert create.status_code == 201, f"Create failed: {create.text}"
    account_id = create.json()["id"]

    # 2. Read-back validation: the stored data must match the payload
    query = f"SELECT Name, Industry FROM Account WHERE Id = '{account_id}'"
    read = requests.get(f"{base}{API}/query", params={"q": query},
                        headers=headers)
    record = read.json()["records"][0]
    assert record["Name"] == payload["Name"], "Name mismatch after create"
    assert record["Industry"] == payload["Industry"], "Industry mismatch"

    # 3. Negative test: a required-field violation must return 400
    bad = requests.post(f"{base}{API}/sobjects/Account",
                        json={"Industry": "Technology"}, headers=headers)
    assert bad.status_code == 400, "Bad payload was accepted"
    assert bad.json()[0]["errorCode"] == "REQUIRED_FIELD_MISSING"

    # 4. Cleanup: delete the record, expect 204
    delete = requests.delete(f"{base}{API}/sobjects/Account/{account_id}",
                             headers=headers)
    assert delete.status_code == 204, "Cleanup delete failed"

    print("All Salesforce API tests passed.")

if __name__ == "__main__":
    try:
        run_tests()
    except AssertionError as e:
        print(f"TEST FAILURE: {e}")
        sys.exit(1)

Four decisions in that script separate it from the tutorial scripts floating around this topic:

• The read-back query validates stored data. Most tutorials print the response and call it verified. This script queries the record back and asserts the fields match the payload, which is the actual promise being tested.

• The negative test asserts the specific error code. A 400 status is not enough. Asserting REQUIRED_FIELD_MISSING confirms the org rejected the payload for the right reason.

• Cleanup runs as a tested step. Tests that leave records behind pollute the sandbox, and polluted sandboxes produce mystery failures for the next run. The delete gets its own assertion.

• Exit codes make CI enforcement real. The script exits 1 on any failure, so a pipeline step fails properly instead of logging green.

Scripts and collections define how tests execute. What they test matters more.

What Test Scenarios Catch Real Salesforce API Defects?

Real Salesforce API defects hide in 5 scenario groups: CRUD with validation rules, status codes, limit behavior, SOQL data checks, and release regression. Coverage of these 5 groups is what I audit first when a client hands me an existing suite. Most suites cover the first half of the first group.

The 5 groups:

• CRUD and data validation: The full record lifecycle, including the rejection side everyone skips.

• Status code assertions: Six codes mapped to the specific defect each one catches.

• Rate and governor limits: Consumption monitored as a value instead of discovered as a surprise.

• SOQL-backed checks: Direct queries validating what writes stored.

• Release-cycle regression: The pre-release pass against preview sandboxes.

Each group below carries its own procedure.

CRUD and Data Validation Scenarios

CRUD scenarios exercise create, read, update, and delete against both standard and custom sObjects. The half everyone skips is the rejection side.

Every validation rule and required field in the org is a promise that bad data gets refused. Each promise needs a test proving the refusal happens with a clear error.

A suite that only proves good payloads succeed will pass while the org silently accepts garbage. In our testing work, rejection-path gaps outnumber happy-path gaps on every inherited suite we audit.

Which Response Status Codes Should You Assert?

Status code assertions map each response to a specific defect class. Six codes cover the ground:

How Do You Test API Rate and Governor Limits?

Rate limit testing verifies how the integration behaves as it approaches the org's daily allocation. Per Salesforce's own limits documentation, an Enterprise Edition org starts at 100,000 API requests per rolling 24-hour period. Each user license adds 1,000 more.

Every response includes a Sforce-Limit-Info header reporting current consumption. Reading it costs nothing:

    used, limit = read.headers["Sforce-Limit-Info"].split("=")[1].split("/")
    assert int(used) / int(limit) < 0.8, "API consumption above 80% of limit"

Integrations discover throttling in production or in a test. Those are the 2 options. The header check above turns limit consumption into a monitored value instead of a surprise.

How Do You Use SOQL in API Testing?

Salesforce Object Query Language (SOQL) gives API tests direct access to stored state. Two uses justify learning it:

• Validation queries: Queries confirm what a write stored, exactly as the Python script above does.

• Setup queries: Queries seed and locate test data without a single UI click, which keeps runtime flat as coverage grows.

The trap sits in relationship queries. Parent-child traversals return nested structures, and assertions that only check the parent level validate half the data. Assert down the tree.

How Do You Test Against Salesforce's Release Cycle?

Release-cycle testing re-runs the API regression suite against preview sandboxes before each of Salesforce's 3 annual releases. Salesforce forces every org onto every release, and the platform retires old API versions on schedule.

Versions 21.0 through 30.0 were retired as of Summer '25. Integrations still pinned to them now receive errors on every call. An integration nobody re-tests breaks on a weekend Salesforce chose, not one you chose.

My pre-release pass is mechanical:

1. Point the full collection at the preview sandbox.

2. Diff the failures against the last production run.

3. Triage anything version-related before the release window closes.

The pass takes hours. The production incident it prevents takes days. Nothing in this article prevents more damage per unit of effort than this habit. The pass runs as standard in our Salesforce QA engagements.

Scenarios define the coverage. A template makes the coverage repeatable across a team.

What Does a Salesforce API Test Case Look Like?

A Salesforce API test case documents 11 fields, from name and endpoint through expected result, actual result, and status. The structure keeps a team's test cases comparable and reviewable.

A filled example beats an empty structure. Here is one from the pattern we run:

Copy the structure. Keep the discipline of filling Actual Result honestly, and the test case doubles as an audit trail.

Templates standardize the what. The remaining choice is the tool that executes it.

Which Salesforce API Testing Tool Should You Choose?

Choose Postman for team-based regression suites, Workbench for instant exploration, and plain scripts for CI-native testing. No single tool wins every scenario, and anyone claiming otherwise is selling one of them.

The 5 realistic options compare like this:

My actual client-project answer is a pair, not a pick. Workbench handles exploration and one-minute verifications. Postman with Newman, or a script suite, handles regression in the pipeline.

Teams that force everything through one tool either slow down their exploration or weaken their automation.

Tool choice closes the core workflow. Three narrower questions still come up on nearly every engagement.

How Do You Test a Salesforce API Connection?

To test a Salesforce API connection, run 3 calls in order: the token request, the versions endpoint, and one sObject describe. Each call isolates a different failure layer, so the sequence diagnoses as it verifies.

The 3 calls:

1. Request a token from /services/oauth2/token. A failure here means credentials, Connected App configuration, or an org policy blocking the flow.

2. Call GET /services/data/ with the token. A failure here means network path, IP restrictions, or an invalid instance URL.

3. Call GET /services/data/v64.0/sobjects/Account/describe. A failure here means the integration user's profile lacks object permissions.

Three green responses confirm the connection end to end. Anything red points at its own layer, which beats reading a generic connection error every time.

Can You Test Salesforce SOAP APIs with SoapUI?

Yes, SoapUI tests Salesforce SOAP APIs through the org's WSDL file. Generate the Enterprise or Partner WSDL from Setup and import it into SoapUI as a new SOAP project. Run the login operation first to capture the session header.

Subsequent operations attach that header.

SOAP testing still matters in one situation I see repeatedly. Legacy enterprise middleware speaks XML and will not migrate this decade. Everything new belongs on REST.

How Does the Agentforce Testing API Change Salesforce Testing in 2026?

The Agentforce Testing API adds programmatic batch evaluation of AI agents, changing the test surface rather than replacing anything. Teams building on Agentforce gain a way to run hundreds of agent evaluations as API calls. Outcomes get assertions, and agent quality wires into the same pipelines that run functional suites.

Everything this article covers stays load-bearing underneath. Agent actions still create records, fire integrations, and consume API limits. The request-level defects stay request-level.

My read for QA leads is direct. Treat agent testing as a new suite in the existing pipeline, not a new discipline that replaces it.

Frequently Asked Questions About Salesforce API Testing

Is Salesforce API Testing Difficult or Easy?

Salesforce API testing is easy to start and moderately difficult to do well. The first Postman request takes under an hour with the official collection. The difficulty concentrates in authentication flow selection, rejection-path coverage, and release-cycle discipline, and each one has its own section above.

Why Use Postman for Salesforce API Testing?

Postman fits Salesforce API testing because the official Salesforce Platform APIs collection removes all endpoint guesswork. Collection-level OAuth handles tokens once for every request. The Tests tab adds real assertions, and Newman carries the whole collection into CI without rework.

Is There an API for Salesforce?

Yes, Salesforce provides 6 API families rather than one API: REST, SOAP, Bulk, Streaming, Tooling, and the Agentforce Testing API. REST serves most modern integration and testing work. The full catalog lives in the Salesforce developer documentation.

Can You Test Salesforce APIs in a Sandbox?

Yes, sandboxes are where all Salesforce API testing belongs until a release gate passes. Sandbox orgs carry their own API allocations separate from production, so test runs never consume production limits. Preview sandboxes host the release-cycle regression pass covered above.

How Do You Check API Usage in Salesforce?

API usage appears in Setup under Company Information, listed as API Requests, Last 24 Hours, against your daily limit. Every API response reports the same consumption through the Sforce-Limit-Info header. The header check in the scenarios section turns that value into an automated assertion.

Do Apex Test Classes Count as Salesforce API Testing?

No, Apex test classes are a separate discipline from Salesforce API testing. Apex tests validate org-side code coverage from inside the platform. API testing validates the request-and-response contract from outside, which is the layer integrations depend on. Both matter, and they answer different questions.