Technical guide

Auth0 technical guide

Everything an engineer needs to connect Auth0 to Salesforce: architecture, the exact build steps with real code, field mapping, the data model, security, monitoring, and the pitfalls we design out.

Platform: Auth0Type: Identity / SSODirection: InboundObjects: User

Auth0 identity and auth-log data flowing into Salesforce. We have shipped it across 1 client project and 5 build tasks.

The value is clean, deduped data landing on the right record the moment it is captured, so nothing is re-keyed and no lead is lost.

We build it the Salesforce-native way: a Connected App and Named Credentials so no secrets ever live in code, field mappings that respect your data model, and record-triggered automation that does the work.

Every Auth0 build is delivered by a senior Salesforce architect on a fixed price, tested end to end in a sandbox, deployed to your org, and backed by 30 days of hypercare. You own the result: documented, source-controlled, and free of black-box middleware lock-in.

the connection at a glancesync active
01Salesforce flow / Apex
02Named Credential
03Auth0 API
04Records
Integration facts

How Auth0 connects to Salesforce

The real connection surface: how it authenticates, what it is built on, the endpoints and events in play, and where the reference docs live.

Connects via
Auth0 as a SAML 2.0 IdP with Salesforce as the SAML Service Provider (SSO into Salesforce)Auth0 as an OpenID Connect provider registered as a Salesforce Auth. ProviderSalesforce as SAML IdP with Auth0 as SP (enterprise connection)Auth0 Log Streams (HTTP/webhook, EventBridge, Event Grid) exporting auth-log data toward Salesforce via middleware
Package
Custom build (no managed package)
Authentication
SAML 2.0 assertions and/or OpenID Connect (OAuth 2.0) ID tokens; the Auth0 Management API uses Bearer JWT access tokens
API type
REST+Webhooks
https://{tenant}.{region}.auth0.com

Key endpoints

/samlp/{clientId} (SAML SSO)/samlp/metadata?connection={name}/login/callback (SAML ACS)/authorize and /oauth/token (OIDC)/api/v2/users and /api/v2/log-streams (Management API)

Webhook and platform events

s (Success Login)f (Failed Login)ss (Success Signup)user.created / user.updated / user.deleted (Event Streams)
Free download

Build this with AI agents

Copy the full playbook as a prompt for any coding agent, or install it as a Claude Code skill. Either way your agent builds with our exact approach: the architecture, the Apex code, the field mapping, the rate limits, and the pitfalls to design out. Free, no signup.

Loading the Auth0 playbook...
Paste into Claude Code, Cursor, or any coding agent
From our builds

What we build for a Auth0 integration

Auth0 identity with user ids and auth-log data flowing into Salesforce and Google Sheets.

1client projects
5delivery tasks shipped

Identity data flow

Flowed Auth0 user ids and auth-log data into Salesforce and Google Sheets so identity activity is visible where teams report.

Real components we ship

Auth0 identityUser id passingAuth-log data flow
Step 0

What you will need

What we confirm on both sides before writing a line of code.

A Salesforce edition with API access (Enterprise, Unlimited, or Developer)
A dedicated sandbox to build and test in
A Auth0 account on a plan with API access
System Administrator access on both systems
A dedicated integration user with a minimum-access permission set
Agreement on the objects, fields, and sync direction for the Auth0 data
How it works

From trigger to record, end to end

The production runtime flow, with what happens in each system.

runtime sequence4 steps
  1. 01

    Action in Auth0

    In Auth0

    A user submits a form, books time, or updates a record in Auth0.

    $The trigger event on the vendor side that starts the flow.
  2. 02

    Data reaches Salesforce

    In transit

    Auth0 sends the payload to Salesforce.

    $Delivered via the Auth0 push or an Apex REST endpoint over Identity / SSO.
  3. 03

    Matched and deduped

    In Salesforce

    Fields are mapped to the User and matched against existing records.

    $Database.upsert on an external-id field so retries never create duplicates.
  4. 04

    User created or updated

    In Salesforce

    The User is written and routed to the right owner, ready for follow-up.

    $A record-triggered flow assigns the owner and fires downstream automation.
Architecture

How the data actually flows

Left to right: sources, the integration layer, Salesforce, and the outcomes it drives.

system architecture
Sources
Auth0
Auth0 form or API
Identity / SSO
Integration layer
Field mapping
Dedupe and matching
Record-triggered flows
Salesforce
User
Related records
Reports
Outcomes
Clean records
No manual entry
Ready for automation

// sources feed the integration layer, Salesforce persists, outcomes ship

Data model

The objects behind the integration

The Salesforce objects we read and write, what each one is for, and the fields that carry the load.

ObjectPurposeKey fields
UserThe primary Salesforce record Auth0 data maps onto.External_Id__c, Name, Status
AccountMatched or created for the customer or company behind the record.Name, External_Id__c
Error_Log__c (custom)Captures every request, response, and failure so anything can be replayed.Payload__c, Status__c, Related_Id__c

Salesforce objects typically in play for Auth0

User (SSO subject mapped via Federation ID / username)ContactLead
Step by step

Build the Auth0 integration

Every step we follow to ship a production-grade build, with the code that matters.

1

Plan the integration and prerequisites

Before any code, we lock down access and design how Auth0 and Salesforce will talk.

  • A Salesforce edition with API access (Enterprise, Unlimited, or Developer) and a dedicated sandbox track
  • A Auth0 account on a plan with API access, plus admin rights on both systems
  • A dedicated Salesforce integration user with a minimum-access permission set, never a personal admin login
  • Decide direction (inbound, outbound, or bidirectional) and cadence (real-time callouts vs scheduled batch)
  • Budget the daily API request allocation and per-transaction callout limits up front
2

Register the app and scope OAuth in Auth0

We create the connection on the Auth0 side and collect exactly the access Salesforce needs.

  • Create an OAuth app or scoped API token in Auth0 to get the Client ID and Client Secret
  • Grant the minimum OAuth scopes required, and note the API base URL and version
  • Whitelist the Salesforce callback URL if the tool uses the authorization-code flow
3

Store secrets with External and Named Credentials

We use the modern Salesforce auth stack, so no secret ever lives in code or metadata.

  • Create an External Credential (OAuth 2.0 or custom) with a named principal
  • Create a Named Credential pointing at the Auth0 base URL and enable the generated authorization header
  • Grant the External Credential through a permission set, so only the integration user can call out
  • This replaces legacy Remote Site Settings and hard-coded tokens entirely

Pro tip: Named Credentials, not code

Named Credentials keep the secret and endpoint out of your Apex and metadata, so nothing sensitive ships in a deployment or lands in version control.

4

Design the data model and external IDs

We make Auth0 records land cleanly on the right Salesforce object with no duplicates.

  • Map every Auth0 field to the User and related objects, documenting type, picklist values, and record types
  • Add a unique, external-id, case-insensitive field on each object as the match key
  • Define owner assignment, required-field defaults, and relationship lookups
5

Build inbound ingestion

If Auth0 data flows in, we ingest it safely and idempotently.

  • Expose an Apex REST resource (@RestResource) or subscribe to Auth0's push or Platform Events
  • Authenticate and parse the payload, then Database.upsert on the external id in bulk
  • Make it idempotent, so a retried or duplicate payload never creates a second record
InboundRecordApi.clsapex
@RestResource(urlMapping='/inbound/records/*')
global with sharing class InboundRecordApi {
  @HttpPost
  global static void upsertRecords() {
    List<Row> items = (List<Row>) JSON.deserialize(
      RestContext.request.requestBody.toString(), List<Row>.class);

    List<MyObject__c> rows = new List<MyObject__c>();
    for (Row r : items) {
      rows.add(new MyObject__c(External_Id__c = r.id, Name = r.name, Amount__c = r.amount));
    }
    upsert rows External_Id__c;         // bulk + idempotent on the external id
    RestContext.response.statusCode = 200;
  }
  global class Row { global String id; global String name; global Decimal amount; }
}
6

Build outbound sync

If Salesforce drives Auth0, we call out the right way.

  • A record-triggered flow to invocable Apex, or an Apex trigger handing off to a Queueable
  • Triggers cannot call out synchronously, so the HTTP callout runs asynchronously
  • Serialize with JSON.serialize and call Auth0 via callout:NamedCredential, handling every status code
SyncToServiceQueueable.clsapex
public class SyncToServiceQueueable implements Queueable, Database.AllowsCallouts {
  private List<Id> ids;
  public SyncToServiceQueueable(List<Id> ids) { this.ids = ids; }

  public void execute(QueueableContext ctx) {
    for (MyObject__c rec : [SELECT Id, Name, External_Id__c FROM MyObject__c WHERE Id IN :ids]) {
      HttpRequest req = new HttpRequest();
      req.setEndpoint('callout:Service_NC/v1/records'); // secret lives in the Named Credential
      req.setMethod('POST');
      req.setHeader('Content-Type', 'application/json');
      req.setBody(JSON.serialize(new Map<String,Object>{
        'externalId' => rec.External_Id__c, 'name' => rec.Name }));
      HttpResponse res = new Http().send(req);
      if (res.getStatusCode() != 200) ErrorLog.capture(rec.Id, res);
    }
  }
}
7

Engineer for scale and governor limits

We build it to survive real volume, not just a demo.

  • Bulkify everything: no SOQL, DML, or callouts inside loops (100 SOQL and 150 DML per transaction)
  • Use Queueable, Batchable, or Scheduled Apex for volume, and chain jobs for large syncs
  • Add retry with backoff and a dead-letter Error_Log__c record for anything that fails
NightlySyncBatch.clsapex
global class NightlySyncBatch implements Database.Batchable<SObject>, Database.AllowsCallouts {
  global Database.QueryLocator start(Database.BatchableContext bc) {
    return Database.getQueryLocator([SELECT Id, External_Id__c FROM MyObject__c WHERE Needs_Sync__c = true]);
  }
  global void execute(Database.BatchableContext bc, List<MyObject__c> scope) {
    ServiceClient.sync(scope);       // one callout per 200-record chunk stays under limits
  }
  global void finish(Database.BatchableContext bc) { /* chain the next job or log the run */ }
}

Watch out: governor limits

Salesforce caps SOQL, DML, and callouts per transaction. Bulkify everything and move volume to Queueable or Batch Apex, or the integration will fail at scale.

8

Lock down security and compliance

We give the integration exactly the access it needs and nothing more.

  • A least-privilege permission set, field-level security, and sharing for the integration user
  • Rotate secrets on a schedule, and add Shield Platform Encryption for sensitive fields where required
9

Test like production

We prove it works before it ships.

  • Apex tests with Test.setMock(HttpCalloutMock) covering success, failure, and a 200-record bulk case
  • At least 75 percent coverage, plus sandbox UAT and a parallel run against the live system
SyncToServiceTest.clsapex
@IsTest
private class SyncToServiceTest {
  private class Mock implements HttpCalloutMock {
    public HttpResponse respond(HttpRequest req) {
      HttpResponse res = new HttpResponse();
      res.setStatusCode(200); res.setBody('{"ok":true}');
      return res;
    }
  }
  @IsTest static void syncsInBulk() {
    Test.setMock(HttpCalloutMock.class, new Mock());
    List<MyObject__c> recs = new List<MyObject__c>();
    for (Integer i = 0; i < 200; i++)
      recs.add(new MyObject__c(Name = 'Row ' + i, External_Id__c = 'EXT-' + i));
    insert recs;

    Test.startTest();     // proves the callout is bulk-safe under governor limits
    System.enqueueJob(new SyncToServiceQueueable(new List<Id>(new Map<Id,MyObject__c>(recs).keySet())));
    Test.stopTest();
  }
}
10

Deploy, monitor, and hand over

We ship it safely and keep it healthy.

  • Deploy via change sets or an SFDX and CI pipeline, and assign the permission sets
  • Turn on monitoring and alerting on the Error Log, and optionally Event Monitoring
  • Hand over with 30 days of hypercare and failure alerting
Field mapping

Example field mapping

How Auth0 data lands on your Salesforce records. We tailor the full mapping to your org.

Auth0SalesforceNotes
Auth0 emailUser.EmailMatch key
Auth0 nameUser.Name
Auth0 companyUser.CompanyRequired on Lead
Auth0 record idUser.External_Id__cUnique external id, upsert key
Auth0 statusUser.StatusPicklist value mapping
Created / updated atLastModifiedDateEnables delta sync and audit
Owner or repUser.OwnerIdAssignment rules or a default owner
API & limits

Rate limits and governor limits

The platform constraints we design around, so the integration stays fast and never falls over at scale.

Specific to Auth0

Auth0 Log Streams retry a failed event delivery up to 3 times
Management API rate limits vary by tenant plan
A SAML SP in Salesforce requires My Domain enabled; the SSO subject must match the User Federation ID or username

Salesforce platform limits

Salesforce caps API calls per 24 hours by edition and license count. We budget the daily allocation up front so the integration never starves other tools.
Per transaction, Apex allows 100 SOQL queries, 150 DML statements, and 100 callouts. We bulkify everything and move volume async to stay well under them.
Auth0 enforces its own rate limits. We honour them, and back off with jitter on HTTP 429 responses instead of hammering the API.
A synchronous callout can run for up to 120 seconds. Anything longer runs in Queueable or Batch Apex, never inline.
Security

Secure by design

How we keep the integration safe, least-privilege, and compliant.

Secrets stored in Named Credentials and permission sets, never in code or metadata
A least-privilege integration user, with field-level security and sharing scoped tight
All traffic over TLS, with signature verification on inbound events
Shield Platform Encryption available for sensitive fields
A full audit trail: every request and response logged for traceability
Every automation runs as a dedicated integration user, so actions are attributable and revocable
Sandbox-first delivery and change-set deployment keep production changes reviewed and controlled
Monitoring

Monitoring, retries, and reliability

What keeps the integration trustworthy in production, and how you know the moment something needs attention.

Every request and response is logged to a custom Error Log object, tagged with the related record id.
Failed calls retry with exponential backoff; anything still failing lands in a dead-letter queue for review.
Idempotency keys guarantee a retried or duplicate event never double-posts a record.
A dashboard surfaces failures, latency, and volume so problems are caught before users notice.
Optional email or Slack alerts fire on repeated failures or a stalled sync.
Testing & deployment

How we test, deploy, and hand it over

The quality gates every build clears before it touches your production org.

Apex unit tests with HttpCalloutMock cover the success path, failure handling, and a 200-record bulk case, at 75 percent or higher coverage.
The full flow is validated in a sandbox against real sample data and the edge cases that matter.
A parallel run reconciles the integration against your live system before cutover.
Everything deploys through change sets or an SFDX and CI pipeline, under version control.
Permission sets, sharing, and Named Credentials are configured in production, then we run 30 days of monitored hypercare.
Pitfalls

Common pitfalls we design out

The mistakes that quietly break integrations, and how we avoid each one.

Duplicate records on retry

Upsert on a unique external-id field so retried payloads are idempotent.

Hitting governor limits at volume

Bulkify and move work to Queueable or Batch Apex; never call out inside a loop.

Callouts failing when a token expires

Use Named Credentials so Salesforce refreshes the OAuth token automatically.

No visibility when it breaks

We log every call and surface failures on a dashboard with alerts, so an issue never goes unnoticed.

Reporting drifts from reality

External-id keys and a delta timestamp keep Salesforce and the source reconciled, so reports stay trustworthy.

Gotchas specific to Auth0

The Name ID / Federation ID from Auth0 must exactly match the Salesforce User Federation ID, and the Name ID Format must be configured correctly
SAML signing certificate rotation on either side breaks SSO if metadata is not re-synced
There is no native Auth0 log-stream destination for Salesforce, so pushing auth logs in requires custom webhook/EventBridge middleware
FAQ

Auth0 integration: technical FAQs

How do you authenticate Auth0 with Salesforce?

We connect Auth0 using secure named credentials and store every secret in Salesforce Named Credentials with a permission set, so nothing is hard-coded or shipped in metadata.

Does the Auth0 integration handle bulk volume?

Yes. All Apex is bulkified, volume moves to Queueable or Batch Apex, and we respect the Salesforce governor limits (SOQL, DML, and callout caps per transaction).

How do you prevent duplicate records?

We upsert on a unique external-id field, so a retried or duplicate payload is idempotent and never creates a second User.

How is the integration tested and deployed?

Apex tests with HttpCalloutMock cover the success, failure, and a 200-record bulk case (75 percent plus coverage). We deploy via change sets or an SFDX and CI pipeline.

What happens if Auth0 or Salesforce is briefly down?

Failed calls retry with backoff and land in an Error Log object with alerting, so nothing is lost and any event can be replayed.

Inbound, outbound, or both?

We build whichever direction you need: an Apex REST endpoint for inbound, record-triggered flows or Queueable callouts for outbound, or both for a two-way sync.

Want us to build your Auth0 integration?

Skip the build. In a free 30-minute call we will map your Auth0 flow and hand you a clear, fixed-price plan.

Ask me anything