What are Named Credentials, and what is their use of them? | Salesforce Named Credentials

Posted by Vinay Vernekar 28th September 2025

Stop hardcoding URLs and start using Salesforce Named Credentials

Look, if you’re still hardcoding endpoint URLs or API keys in your Apex classes, we need to talk. It’s a security risk, it’s a nightmare to maintain, and frankly, it’s just not how we build things anymore. Salesforce Named Credentials are the solution to this headache, and if you aren’t using them yet, you’re making your life harder than it needs to be.

So, what are they exactly? Think of them as a secure vault that holds both the “where” (the URL) and the “how” (the authentication) for your external callouts. Instead of writing out a full URL and manually building headers in your code, you just point to the credential. Salesforce handles the messy parts of the handshake for you.

The real benefits of Salesforce Named Credentials

I’ve seen teams spend hours debugging why an integration broke in a sandbox, only to realize someone forgot to update a hardcoded URL. When you use these credentials, you update the URL in one place in the Setup menu, and every Flow or Apex class using it just works. No code deployments required.

Here’s another huge plus: you can usually skip the Remote Site Settings entirely. Since the platform already knows about the endpoint through the credential, it trusts the connection. It’s one less piece of metadata to track. Plus, your secrets stay out of your git repo. I’ve worked on audits where the first thing they look for is “password” or “apiKey” in the codebase. Don’t be that person.

Pro tip: Always use Named Credentials for your Salesforce API integration strategy. It makes moving between dev, test, and production environments much smoother since you just swap the credential details in each org.

Breaking down the components

When you go to set one up, you’ll see a few fields that might look confusing at first. Here is what actually matters:

  • Label and Name: This is the nickname you’ll use in your code (like callout:My_API_Service).
  • URL: The base address of the service, like https://api.stripe.com.
  • Identity Type: This is where most people get tripped up. Do you want every user to share one login (Named Principal), or does the external system need to know exactly who is calling (Per User)?
  • Authentication Protocol: Whether you’re using a simple password, AWS Signature, or OAuth 2.0.

Named Principal vs Per User: Which one do you need?

Here’s the thing: most of the time, you’ll want Named Principal. This is perfect for system-to-system integrations where Salesforce is talking to a service using one master account. It’s easy to manage and less likely to break when a single user leaves the company.

But sometimes you need Per User. I’ve used this when integrating with something like Google Drive, where each Salesforce user needs to see their own files. It’s more secure because it respects individual permissions, but it does mean every user has to click “Authorize” at least once. It’s a trade-off between security and convenience.

Using Salesforce Named Credentials in your code

The beauty of this setup is how clean the code looks. You don’t have to worry about req.setHeader('Authorization', 'Bearer ' + token) anymore. You just use the callout: prefix in your endpoint. Here is a quick example of how I usually write these:


HttpRequest req = new HttpRequest();
req.setEndpoint('callout:Payment_Gateway/v1/charges');
req.setMethod('POST');
Http http = new Http();
HTTPResponse res = http.send(req);

It’s that simple. Salesforce sees the callout: tag, looks up your credential, grabs the token or password, and attaches it to the request before it leaves the server. If you’re using a Salesforce JWT flow, this becomes even more powerful because the platform manages the entire token exchange behind the scenes.

What about Flows?

If you’re more of a declarative builder, you can use these in Flow too. When you use the “HTTP Callout” button in Flow Builder, Salesforce asks you for a Named Credential right away. It’s a great way to keep your automation secure without writing a single line of Apex. If you’re debating which way to go, check out this guide on Apex vs Flow to see what fits your project better.

Key Takeaways

  • Security first: Stop putting passwords in Custom Metadata or hardcoded strings.
  • Maintenance: Update endpoints in Setup, not in your code.
  • Identity: Use Named Principal for shared system access and Per User for individual access.
  • No Remote Site Settings: Usually, you won’t need them if you’re using a Named Credential.
  • Works everywhere: Use the same credential in Apex, Flow, and External Services.

Wrapping it up

Salesforce Named Credentials are one of those “set it and forget it” features that make your life as a developer or admin so much easier. They keep your org secure, your code clean, and your integrations reliable. If you’re still doing things the old way, take 15 minutes today to migrate one of your callouts. You’ll thank yourself the next time you have to rotate an API key or change a server URL.

Tags: