Named Credentials

💬 In plain words: Think of these as two completely separate security allow-lists that guard different doors. Remote Site Settings give your Salesforce backend server (Apex or Flow HTTP Callout) permission to call an external URL. CSP Trusted Sites (now grouped under Trusted URLs in Salesforce Setup) give the user's web browser (LWC or Aura) permission to fetch data, images, or scripts from an external URL. If an Apex callout fails, check Remote Site Settings or Named Credentials . If a browser request fails inside an LWC, check your CSP Trusted Sites! 📌 Real-Life Example: Imagine you are building a live weather dashboard on an Account page. First, your Apex class tries to fetch weather data from https://api.weather.com , and Salesforce immediately throws a System.CalloutException: Unauthorized endpoint error. Why? Because the Salesforce server blocked the call. The fix is adding a Remote Site Setting (or better yet, a Named Credential). Later tha...

💬 In plain words: Modern Salesforce architecture splits Named Credentials into two clean parts so you never have to hardcode URLs or API passwords inside Apex code. The External Credential acts as the security recipe—it stores how you log in (like OAuth 2.0 or API keys) and controls who is allowed to make the callout using Permission Sets. The Named Credential acts as the destination address—it stores where the callout goes (the base URL) and links back to the External Credential. Password rotation, encrypted tokens, and user permissions stay safely inside Salesforce Setup, never exposed in your code! 📌 Real-Life Example: Imagine your company connects Salesforce to an external SAP ERP system that has three different microservice URLs: api.sap-erp.com/orders , api.sap-erp.com/invoices , and api.sap-erp.com/inventory . In the old days, you had to create three separate Legacy Named Credentials and type the exact same OAuth Client ID and Secret three times. ...

💬 In plain words: Named Credentials encapsulate target callout URLs and authentication parameters into declarative setup records. By referencing endpoints with the callout: protocol in Apex, you automatically eliminate hardcoded credentials and bypass explicit Remote Site Settings. Named Credentials are a powerful feature in Salesforce that allow you to securely authenticate and connect to external services and APIs without exposing sensitive information like usernames and passwords. In this blog post, we'll delve into the world of Named Credentials, understand their significance, and provide you with in-depth code examples to illustrate their implementation in various scenarios.

💬 In plain words: An Apex callout is Salesforce making a phone call to an outside system's API. Named Credentials and External Credentials are your secure phonebook. They store the address (URL) and the login details (like OAuth tokens or an API key), so your code holds no secrets at all. Your code just says callout:My_Named_Credential , and Salesforce adds the login details for you. And a Lightning Web Component (LWC) should never make this call straight from the browser. It should ask Apex to make it. 📌 Example: A user clicks "Check Credit Score" in an LWC. The LWC calls an Apex method. Apex makes the callout to callout:CreditAPI/score through a Named Credential. The browser never sees the API URL or the secret key. If the API password changes, an admin updates it in Setup. No code change, no deployment.

In plain words: Integrating external services in Salesforce Lightning Web Components (LWC) allows your custom UI to communicate with third-party APIs and legacy software. By leveraging secure Named Credentials and standard JavaScript fetch methods or Apex controllers, your components can pull live external data, process payloads, and update the user interface in real time. Modern enterprise applications rarely operate in isolation. Businesses frequently need to connect their Salesforce CRM with external web services, payment gateways, shipping providers, or custom microservices. Lightning Web Components (LWC) provide a secure, modular framework to interact with external APIs directly from the browser or through an intermediary Apex controller.

In plain words: An Access Token is like a temporary digital keycard that lets Salesforce call external APIs securely without sending usernames and passwords on every request. Because access tokens expire quickly for safety, a long-lived Refresh Token is used behind the scenes to request a brand-new access token automatically without breaking background integrations. Connecting Salesforce to external third-party systems requires secure, standard authorization. The OAuth 2.0 framework is the industry standard for granting applications secure delegated access. When making outbound REST callouts or building custom OAuth token managers in Apex, handling initial token issuance and subsequent refresh cycles properly prevents service downtime and protects sensitive API credentials.

In plain words: Integrating Google Drive with Salesforce allows your CRM to directly read, list, and upload files to Google Cloud storage. By authenticating via OAuth 2.0 and executing REST callouts in Apex, teams can offload heavy file storage from Salesforce, organize customer documents into Google Drive folders, and maintain real-time access right from record pages. Salesforce orgs frequently hit data and file storage limits when storing heavy contracts, collateral, and customer uploads as native ContentDocument records. Integrating directly with Google Drive via the Google Drive REST API v3 offers a cost-effective, scalable solution. This guide walks through setting up OAuth credentials in Google Cloud, structuring robust Apex callout methods, and executing multipart file uploads safely.

In plain words: Integrating the Google Address & Geocoding API with Salesforce allows your CRM to convert partial or unstructured address strings into validated street names, cities, postal codes, and precise latitude/longitude coordinates. By making HTTP callouts from Apex or Lightning Web Components (LWC), organizations can standardize billing and shipping addresses automatically and eliminate bad data before records are saved. Inaccurate customer addresses lead to delivery delays, bad tax calculations, and dirty CRM data. While Salesforce provides native custom address fields, verifying real-time global addresses and fetching geolocation coordinates requires an external location intelligence service. Integrating the Google Maps Geocoding & Places API into Salesforce solves this by giving users autocomplete validation, street-level accuracy, and clean data parsing directly in their CRM workflows.

In plain words: A Salesforce Session ID (or OAuth access token) acts as a digital key that proves your identity to Salesforce. Once authenticated, external applications pass this token in the Authorization: Bearer <Session_ID> header to query database records, execute REST/SOAP APIs, or trigger automations without re-entering login credentials on every request. Connecting third-party platforms, microservices, or custom scripts to Salesforce requires a valid authentication token. Whether you are building an integration using legacy SOAP web services or modern REST APIs, obtaining a session ID is the first step. Below is a breakdown of how to retrieve session IDs using SOAP login requests, native Apex methods, and modern OAuth 2.0 standards.

In plain words: External API integration in Lightning Web Components (LWC) allows Salesforce components to send requests to third-party web services—such as toll calculation, mapping, or payment gateways. In Salesforce, you can invoke external endpoints either directly from JavaScript using the browser's fetch() API (with CSP Trusted Sites enabled) or securely through an Apex callout using Named Credentials . Connecting Salesforce applications with external web services is a core requirement in logistics, fleet management, and finance. For instance, querying a toll calculation service allows transportation teams to estimate route costs dynamically from an Account or Work Order page. Below, we break down how to configure network permissions and execute external API requests cleanly from an LWC component.

In plain words: SOAP API integration in Salesforce Apex enables your org to exchange structured, XML-based messages with external enterprise systems. By importing a WSDL document into Salesforce using the built-in WSDL2Apex wizard, the platform auto-generates strongly typed Apex classes that use WebServiceCallout.invoke to send requests and parse responses with minimal manual parsing. While lightweight REST integrations with JSON payloads dominate modern web APIs, many mission-critical enterprise systems—including legacy ERPs, banking networks, and government data exchanges—rely strictly on the SOAP (Simple Object Access Protocol) standard. Salesforce Apex provides native support for both consuming external SOAP services via WSDL2Apex callouts and exposing custom Apex methods as SOAP web services.

In plain words: A dynamic HTTP callout in LWC allows users to input target API endpoints, custom headers, and request bodies directly from a Lightning UI, sending those parameters to an Apex controller that securely executes the REST callout and returns the real-time response. Modern enterprise applications frequently need to test, query, or sync with third-party web services. By combining Lightning Web Components with Apex HTTP classes, you can build a flexible API client inside Salesforce to send GET, POST, or PUT requests to any configured external endpoint on demand.

Synchronizing high-volume data between Salesforce and Google Workspace is a common architectural requirement. Instead of making individual HTTP callouts for every single row—which quickly burns through Salesforce governor limits—you can leverage Google Sheets batch APIs to read and write large sets of spreadsheet data in a single roundtrip. In plain words: A Google batch integration bundles multiple spreadsheet updates or reads into one HTTP request from Salesforce Apex, drastically saving API limits and cutting transaction times.