What is a Named Credential? | CRM Curator

A Named Credential is a Setup-level record that stores an external service’s URL and how to authenticate to it — usernames, passwords, OAuth tokens, certificates. Apex references it by name (callout:My_API) and the platform handles the auth handshake at runtime.

Why they exist

Before Named Credentials, integrating with an external API meant:

Hardcoding the endpoint URL in Apex
Storing the API key in a Custom Setting or Custom Metadata Type
Building the Authorization header by hand
Adding the host to Remote Site Settings

Every one of those is a maintenance burden and a security review failure. Named Credentials collapse all four into one Setup record.

The modern shape (Spring ‘23 onward)

Named Credentials were redesigned a couple of years ago into a two-record model:

Record	Purpose
External Credential	The auth method — OAuth 2.0, AWS Signature v4, JWT, basic, custom header. Holds the principal (per-user or per-org).
Named Credential	The endpoint URL, plus a reference to the External Credential.

One External Credential can be reused by many Named Credentials — useful when one service has multiple base URLs (sandbox, prod, EU region).

How Apex consumes it

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:Stripe_API/v1/customers');
req.setMethod('GET');
HttpResponse res = new Http().send(req);

That’s it. No Authorization header in code. Salesforce:

Resolves Stripe_API to its URL (https://api.stripe.com).
Pulls the auth principal from the External Credential.
Builds the right header (e.g. Authorization: Bearer eyJ...).
Refreshes the OAuth token if expired.
Sends the request.

Supported authentication protocols

OAuth 2.0 — authorization code, client credentials, JWT bearer, refresh token flows
AWS Signature v4 — for direct calls to AWS APIs (S3, Lambda, etc.)
JWT — for stateless service-to-service
Basic — username/password (use sparingly)
Custom — your own header logic via callouts to a custom Apex class

Per-user vs per-org credentials

External Credentials hold Principals. A Principal can be:

Named Principal — one set of creds for the whole org (typical for service accounts)
Per-User Principal — each user authenticates separately (used when the external system needs to know which Salesforce user is calling, e.g. Google Workspace integrations)

Why interviewers ask about this

It’s the canary question for whether you’ve actually shipped integration code in the last few years. Anyone who’s only read older tutorials will describe storing tokens in Custom Settings. Anyone who’s been near Security Review will immediately reach for a Named Credential.

Verified against: Salesforce Help — Named Credentials. Last reviewed 2026-05-17 for Spring ‘26 release.