Get Request
A GET Request in Salesforce is an HTTP request that uses the GET method to read data from a web resource.
Definition
A GET Request in Salesforce is an HTTP request that uses the GET method to read data from a web resource. Salesforce both produces and consumes them. Apex code builds a GET callout to pull data from an external API, and the Salesforce REST API answers GET requests on its own endpoints to return records, query results, and org metadata as JSON.
GET is the read-only verb of HTTP. It sends no body, so all input travels in the URL as the path and the query string. It is idempotent, meaning a repeated call returns the same result and changes nothing on the server. That safety is why GET is the default verb for most integrations, why intermediaries can cache its responses, and why it is the easiest callout to test and retry. The same per-org callout limits, timeout ceiling, and response size cap apply whether the verb is GET or anything else.
Where GET requests show up across the platform
Building a GET callout in Apex
Apex makes outbound HTTP calls with three classes. HttpRequest holds the verb, endpoint, headers, and timeout. The Http class sends it. HttpResponse carries the status code, headers, and body that come back. A GET callout sets the method to GET, sets the endpoint URL, adds any headers the API needs, then calls Http.send(request). GET is the default when no method is set, but production code should still call setMethod('GET') so the intent is obvious to the next reader. The endpoint can include a query string, and Apex does not encode it for you. Run EncodingUtil.urlEncode on any value that comes from user input or record data, or a stray space or ampersand will corrupt the URL. Once the response returns, read getStatusCode() to confirm success before parsing getBody(). A 200 means the read worked. A 401 or 403 points at authentication, and a 404 means the resource path is wrong. Wrapping the parse step in a check for the expected status keeps a bad response from throwing deep inside your JSON logic.
The Salesforce REST API answers GET
Salesforce exposes its own data through a REST API that responds to GET on nearly every resource. A GET to /services/data/v60.0/sobjects/Account/001xx000003DGb2 returns that one record as JSON. A GET to /services/data/v60.0/query/?q=SELECT+Id,Name+FROM+Account runs a SOQL query and returns the matching rows. A GET to /services/data/v60.0/limits reports how much of each governor allocation the org has used, and a GET to /services/data/ lists the API versions the instance supports. The base URL is your My Domain instance URL, the version sits in the path, and the OAuth access token rides in the Authorization header as a bearer token. You can trim the payload on a record read by adding a fields parameter so only the columns you list come back. This is the same API that powers external apps, middleware, and many of Salesforce's own clients, so a GET request here is a first-class way to read platform data from anywhere.
Named Credentials carry the authentication
Hard-coding an endpoint URL and a secret key inside an Apex class is an anti-pattern. It leaks credentials into source control, breaks in managed packages, and fails security review. A Named Credential solves this by storing the callout endpoint and its authentication in Setup, paired with an External Credential that holds the protocol and the secrets. Apex then targets the callout by name. Writing setEndpoint('callout:My_API/users/123') tells the platform to resolve the real URL and inject the auth header at runtime, so the access token never touches your code. The same pattern works for GET callouts made from Flow and from External Services. Salesforce reworked Named Credentials in Winter '23 into the extensible External Credential model, and the older legacy style still works but no longer gets new features. Using a Named Credential also means a GET callout skips the Remote Site Settings allowlist, because the named endpoint is already a trusted, registered destination.
Declarative GET through External Services and Flow
Not every GET integration needs Apex. External Services lets an admin import an OpenAPI specification for an external API, and Salesforce reads each operation in that spec. A GET operation, such as one that returns a user by ID, becomes an invocable action you can drop into a Flow. The path and query parameters from the spec turn into action inputs, and the response body becomes the action output as flow variables. The platform generates the callout under the covers, so a simple read-and-display integration ships with clicks instead of code. These same imported operations are available as invocable actions to agents and to other automation that can call invocable methods. The catch is that the generated action is only as good as the OpenAPI spec it came from. A spec with vague response schemas or missing parameter definitions produces an action that is awkward to map in Flow, so the quality of the source document matters more here than it does when you hand-write the callout.
Limits that apply to every GET
A GET callout is governed like any other callout. An Apex transaction can make up to 100 outbound callouts, counting synchronous and asynchronous calls together. Each callout has a configurable timeout that defaults to 10 seconds and can be raised to a maximum of 120 seconds with setTimeout, expressed in milliseconds. The HTTP response body is capped at roughly 6 MB for synchronous Apex and 12 MB for asynchronous Apex, shared with the request heap. A GET that pulls a large dataset or talks to a slow API can blow past the timeout or the size cap, so move long or heavy reads into a Queueable or another asynchronous context where the ceilings are higher. There is one ordering rule that trips up beginners. You cannot make a callout after you have performed uncommitted DML in the same transaction. The platform throws a CalloutException about pending uncommitted work. Either run your GET before the DML, or push the database writes into an asynchronous method so the callout runs cleanly.
Caching, idempotency, and safe retries
Because GET changes nothing on the server, it is safe to call again when something goes wrong. That makes retry logic simple. Wrap the callout in a loop that catches a transient failure, waits a moment, and tries once more, ideally with a short backoff between attempts. The same property lets intermediaries cache GET responses. A CDN or an API gateway can store the result and serve it without touching the origin, which is great for read performance but a problem when you need fresh data. If a response must never be cached, the called API has to send a Cache-Control header that forbids storage, or your caller has to add a unique throwaway query parameter to defeat the cache. On the Salesforce side, repeating the same GET wastes part of your 100-callout budget, so cache the result yourself. Platform Cache or a custom object with a time-to-live field can hold the payload for a window, letting later requests read from the org instead of spending another callout.
Set up a Named Credential for a GET callout
To let Apex or a Flow make a GET callout to an external API, set up the endpoint and its authentication in Setup first. The recommended path is a Named Credential, which registers a trusted destination and handles the auth header for you. Configure it once and every GET callout that targets it stays clean and packageable.
- Create the External Credential
In Setup, open Named Credentials and switch to the External Credentials tab. Add an external credential, choose the authentication protocol the API uses, such as OAuth 2.0 or a custom header, and add a principal that holds the actual secret or token.
- Create the Named Credential
On the Named Credentials tab, click New. Enter the base URL of the API, link the External Credential you just made, and keep the option to generate the authorization header enabled so the platform injects it on every call.
- Grant access through a permission set
Open the External Credential principal and add it to a permission set, then assign that permission set to the users or the integration user whose context will run the GET callout. Without this grant the callout fails on authentication.
- Reference it from your GET callout
In Apex, set the endpoint to callout:Your_Named_Credential plus the resource path and call setMethod('GET'). In Flow, point the External Service action at the same named endpoint. The platform resolves the URL and adds the auth header at run time.
The base endpoint of the external API, for example https://api.example.com. Resource paths get appended after the named-credential reference in your callout.
Set on the External Credential. Choose OAuth 2.0, JWT, AWS Signature, or a custom header to match what the target API requires.
When enabled, Salesforce builds and attaches the auth header automatically so your code never handles the token. Disable it only if you need to set the header yourself.
Controls which packaged or org namespaces may use the credential, which matters when the callout ships inside a managed package.
- A Named Credential endpoint bypasses Remote Site Settings, but a raw hard-coded URL does not. If you skip the Named Credential, add the host to Remote Site Settings or the callout is blocked.
- Forgetting to assign the External Credential principal to a permission set is the most common cause of a GET callout failing with an authentication error right after setup.
- Legacy Named Credentials still function but receive no new features. Build new ones on the External Credential model introduced in Winter '23.
Prefer this walkthrough as its own page? How to Get Request in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Get Request.
Hands-on resources to go deeper on Get Request.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does an HTTP GET Request do within an API integration with Salesforce?
Q2. When you make a GET callout from Apex, which detail genuinely matters to get it right?
Q3. Which limits apply to a GET callout under the standard Apex callout governor rules?
Discussion
Loading discussion…