Imagine you arrive at a building you’ve never visited, walk up to the front desk, and say “let me in.” The receptionist, quite reasonably, asks who you are and whether you’re expected. Integration works exactly the same way. Before one system hands over its data, it wants proof of identity. That proof is called authentication, and it’s the quiet gatekeeper standing in front of every API you’ll ever use.
Let me show you the three ways you’ll meet this gatekeeper, from the simplest to the one I’d recommend you reach for inside Salesforce.
Why this matters before anything else
You can write a perfect request — correct URL, clean JSON, the right verb — and still get rejected with a curt “401 Unauthorized.” That’s the other system saying “I don’t know who you are, so I’m not letting you in.” Authentication isn’t an afterthought you bolt on at the end. It’s the first handshake, and if it fails, nothing else happens.
API keys: the simple password
An API key is the simplest form of proof. It’s a long string of characters the other system gives you, and you include it with every request. Think of it as a password printed on a card you flash at the door. Many services hand you one and that’s the whole story.
API keys are easy to start with, which is their charm. But they have a weakness: a key is a single secret that usually doesn’t expire. If it leaks, whoever holds it can act as you indefinitely. That’s why simple keys are fine for low-risk services but rarely the choice for serious enterprise connections.
OAuth: tokens instead of passwords
OAuth is the modern standard, and it solves the leaking problem with a clever idea. Instead of carrying one permanent password, your system proves its identity once and receives a short-lived access token in return. You use that token for your requests, and it expires after a while. When it does, you quietly request a new one.
The beauty is that even if a token leaks, it’s useless within minutes. And you never had to hand over a permanent password in the first place. OAuth has more moving parts than an API key — there’s a flow of requests to get that token — but it’s worth understanding, because it’s what most reputable APIs use today. When you connect Salesforce to Stripe, to a partner system, or to your own MuleSoft layer, OAuth is very likely doing the work underneath.
A password says “trust me forever.” A token says “trust me for the next hour.” That single difference is most of what makes modern authentication safe.
The rule that protects you: never hardcode secrets
Here’s the mistake I see beginners make, and I made it too. You’re testing an integration, you have an API key, and you paste it straight into your Apex code to make it work. It works. You move on. Months later that code ends up in a place you didn’t expect — a deployment, a log, a screen share — and your secret is out in the world.
A secret written into code is a secret you’ve lost control of. So the rule is simple and absolute: never put keys, passwords, or tokens directly in your code. Keep them somewhere designed to guard them.
Named Credentials: the Salesforce way to do it right
This is where Salesforce gives you something genuinely lovely. A Named Credential is a secure place to store the address of an external system and the credentials needed to reach it — completely separate from your code. Your Apex just references the Named Credential by name and says “call this endpoint.” Salesforce attaches the authentication for you, behind the scenes, without the secret ever appearing in your code.
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_External_Service/v1/orders');
req.setMethod('GET');
// No keys, no tokens in the code — the Named Credential handles auth
HttpResponse res = new Http().send(req);Notice the callout: prefix and the absence of any secret. Salesforce can even manage the whole OAuth token dance for you, refreshing tokens automatically so you never touch them. This is the secure, professional pattern, and I’d encourage you to use it from your very first real integration. It keeps your secrets out of your code, out of your logs, and out of trouble.
How to think about choosing
You usually don’t pick the authentication method — the external system tells you what it accepts. Your job is to recognize it and respond well: store an API key in a Named Credential rather than your code; let Salesforce manage OAuth tokens for you. The principle never changes. Prove who you are, and never let your proof leak.
Your next step
Authentication is the handshake; now learn the conversation that follows. Start with Salesforce Integration for Beginners for the full picture, then read REST vs SOAP APIs to understand the two request styles you’ll be authenticating into. The complete path lives in the Integration category.