Skip to Content
TwinsSalesforce

Salesforce

Twin of the Salesforce REST API and OAuth.

Twin of the Salesforce REST API and OAuth.

Coverslogin.salesforce.com, *.my.salesforce.com
AuthOAuth 2.0 bearer, authorization code and refresh token
WebhooksNo
Operations61

Coverage

sObject CRUD and upsert by external id, describe, SOQL and SOSL with query locators, composite, batch, graph and collections, Bulk 2.0 ingest and query jobs, ContentVersion blobs, and the OAuth authorize, token, revoke and userinfo endpoints. Real Salesforce splits the login host from your instance host, and both are served here.

Every version from v31.0 to v67.0 is accepted and all of them return the same representation. Resource URLs echo whichever version you asked for, and anything outside the window is a 404.

Credentials

API calls take Authorization: Bearer. Only tokens the twin minted work, so run your own connect flow against it or read a seeded token from /veris/data. See Credentials.

PKCE is required on the authorization code flow. An authorize without a code_challenge redirects with invalid_request, and a token exchange with no challenge bound to the code is invalid_grant. The grants are authorization code and rotating refresh token, with no JWT bearer and no client credentials.

Scopes are enforced, and a token without api or full gets Salesforce’s own 401 INVALID_SESSION_ID rather than a 403.

Vendor specific details

  • Errors are a JSON array even when there is one of them: [{"message", "errorCode", "fields"}].
  • A create is 201 with a body. A PATCH update and a DELETE are both 204 with no body at all, so there is nothing to parse and nothing to assert on.
  • Ids always come back in canonical 18-character form even when you addressed the record with the 15-character one. Comparing what you sent against what you got back fails.
  • An unknown sObject name is a 404 NOT_FOUND. INVALID_TYPE shows up only as a per-subrequest status inside composite and collections responses.

Its own notes

Once a sandbox is running, this twin serves its own operating notes at {control_url}/veris/manual: the credentials it accepts, the API versions it serves, and the fault statuses you can arm against it. They are generated from the same source as its behaviour, so they cannot drift.