Stop hardcoding URLs and start using Salesforce Named Credentials
If you're still hardcoding endpoint URLs or API keys in your Apex classes, we need to talk. It's a security risk and a nightmare to maintain, and frankly, it's just not how we build things anymore. Salesforce Named Credentials are the fix, and if you aren't using them yet, you're making your life harder than it needs to be.
A Named Credential is 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.
You can also 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. Your secrets stay out of your git repo too. 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 each one does:
- Label and Name: 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?
Most of the time, you'll want Named Principal. It fits 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.
Sometimes you need Per User instead. 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. That's the trade-off between security and convenience.
Using Salesforce Named Credentials in your code
The code gets a lot cleaner. 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);
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. With a Salesforce JWT flow it goes further, 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 keeps 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
- Stop putting passwords in Custom Metadata or hardcoded strings.
- Update endpoints in Setup, soql-not-in-not-equal-exclusion/" class="auto-link">not in your code.
- Named Principal for shared system access, Per User for individual access.
- You usually won't need Remote Site Settings if you're using a Named Credential.
- The same credential works 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.
Leave a Comment