Salesforce
Twin of the Salesforce REST API and OAuth.
Twin of the Salesforce REST API and OAuth.
| Covers | login.salesforce.com, *.my.salesforce.com |
| Auth | OAuth 2.0 bearer, authorization code and refresh token |
| Webhooks | No |
| Operations | 61 |
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_TYPEshows 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.