How do I mock the Salesforce REST API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:salesforce-style), and run stunt up. You get a local, stateful stand-in for Salesforce REST API v60.0 — 29 routes over rest — with no remote account, no network, and no bills.

Is the Salesforce REST API mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Salesforce REST API (routes, status codes, pagination, webhooks), never real records.

← all adapters

salesforce-style

simulates Salesforce REST API v60.0

restadapter v0.1.029 routes

verification

SDKverified with jsforce 3.10.22 (floor)· surface 29 · not implemented 7 · differs 4

use it

# add to stunt.yaml
services:
  salesforce:
    adapter: embedded:salesforce-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Salesforce REST API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Salesforce REST API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Salesforce REST API v60.0 surface — the data is fake, the behavior is real.

backing stores

access_tokensaccountscontactsopportunitiesleadsusers

api surface (29)

generated from the adapter manifest — exactly what boots, nothing more

29 routes

POST/services/oauth2/token

GET/services/data/v60.0/sobjects

GET/services/data/v60.0/sobjects/Account

GET/services/data/v60.0/sobjects/Contact

GET/services/data/v60.0/sobjects/Opportunity

GET/services/data/v60.0/sobjects/Lead

GET/services/data/v60.0/sobjects/User

POST/services/data/v60.0/sobjects/Account

GET/services/data/v60.0/sobjects/Account/{id}

PATCH/services/data/v60.0/sobjects/Account/{id}

DELETE/services/data/v60.0/sobjects/Account/{id}

PATCH/services/data/v60.0/sobjects/Account/{extIdField}/{extIdValue}

POST/services/data/v60.0/sobjects/Contact

GET/services/data/v60.0/sobjects/Contact/{id}

PATCH/services/data/v60.0/sobjects/Contact/{id}

DELETE/services/data/v60.0/sobjects/Contact/{id}

PATCH/services/data/v60.0/sobjects/Contact/{extIdField}/{extIdValue}

POST/services/data/v60.0/sobjects/Opportunity

GET/services/data/v60.0/sobjects/Opportunity/{id}

PATCH/services/data/v60.0/sobjects/Opportunity/{id}

DELETE/services/data/v60.0/sobjects/Opportunity/{id}

PATCH/services/data/v60.0/sobjects/Opportunity/{extIdField}/{extIdValue}

GET/services/data/v60.0/query

GET/services/data/v60.0/queryAll

GET/services/data/v60.0/query/{queryLocator}

POST/services/data/v60.0/composite

POST/services/data/v60.0/composite/sobjects

PATCH/services/data/v60.0/composite/sobjects

DELETE/services/data/v60.0/composite/sobjects

SDK-verified behaviors (6)

✓SDK-driven login: with clientId+clientSecret configured, jsforce's conn.login rides the OAuth2 password grant itself, and adopts the adapter's echoed instance_url as its API base
✓sobject create assigns an id
✓retrieve round-trips the fields
✓update patches and persists
✓SOQL through the SDK's query parser
✓destroy removes the record

Not implemented (7)

No Lead or User CRUD routes
No query or queryAll sub-requests in composite batches
No SOSL search (GET /search)
No composite tree upsert (POST /composite/tree)
No batch endpoint (GET /composite/batch/sobjects)
No Bulk API 2.0 (jobs/ingest, jobs/query)
No GET updated/deleted incremental-refresh endpoints

Differs from the real API (4)

instance_url echoes the caller host over http:// (real: the org https:// instance)
Governor limits (100 SOQL/txn, 10k DML rows) documented but not enforced
SOQL WHERE subset: no parenthesized grouping; date literals compared lexically
Password grant accepted for convenience; real SF requires web-server or JWT flow

full scorecard →

want more of the Salesforce REST API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.