Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryGGet Request
DevelopmentBeginner

Get Request

A GET Request in the Salesforce context is an HTTP request using the GET method, typically used to read data from a REST API.

§ 01

Definition

A GET Request in the Salesforce context is an HTTP request using the GET method, typically used to read data from a REST API. The Salesforce platform consumes and produces GET requests across several integration surfaces: Apex HTTP callouts use HttpRequest.setMethod('GET') to read from external APIs; the Salesforce REST API exposes endpoints like /services/data/v60.0/sobjects/Account that respond to GET with sObject data; External Services and Named Credentials wrap GET callouts as declarative actions in flows; and Visualforce remoting historically used GET for read-only Apex method calls.

GET is the default and safest HTTP verb in any integration because it carries no payload, can be cached by intermediaries, and is idempotent (calling it twice produces the same result as calling it once). Salesforce enforces a 6-MB synchronous response size limit, a 120-second timeout, and the standard per-org callout limits regardless of whether the call is GET or another verb. Authentication, headers, and query-string parameters travel with the GET; the response body carries the payload.

§ 02

How GET shows up across Salesforce integration surfaces

Apex callouts with HttpRequest

The HttpRequest class supports GET, POST, PUT, PATCH, DELETE, and HEAD. A GET callout sets the method, the endpoint, and any headers, then sends via Http.send(). The HttpResponse contains the body, headers, and status code. GET is the default when method is unset, but production code should always call setMethod('GET') explicitly. Endpoint URLs can include query-string parameters; Apex does not encode them automatically, so EncodingUtil.urlEncode is required on user-supplied values.

Salesforce REST API as the GET target

Salesforce's own REST API responds to GET on every resource: /services/data/v60.0/sobjects/Account/001xx000003DGb2 returns the JSON record, /services/data/v60.0/query?q=SELECT+Id+FROM+Account runs a SOQL query, /services/data/v60.0/limits returns org limits. The base URL is the instance URL (https://yourdomain.my.salesforce.com), the version comes from the path, and the OAuth bearer token comes in the Authorization header.

Named Credentials hide the auth plumbing

Named Credentials store the endpoint URL, the authentication protocol (OAuth, JWT, mutual TLS), and the credentials in Setup. Apex callouts and External Services then reference the Named Credential by name (callout:MyApi/users/123) and the platform injects the auth header automatically. GET requests through a Named Credential are the recommended pattern; raw endpoints with hard-coded keys are an anti-pattern.

External Services and flow integration

External Services lets admins import an OpenAPI spec and exposes each GET operation as a declarative Flow action. The flow passes inputs as path or query parameters; the External Service handles the HTTP call and returns the response as flow variables. This removes the need to write Apex for simple GET-and-return integrations; the platform generates the callout code at registration time.

Caching, idempotency, and retries

GET is safe to retry because it does not change state on the server. Apex code can wrap GET callouts in a retry loop with exponential backoff when transient failures occur. Intermediaries (CDN, gateway) can cache GET responses; if the data must not be cached, the called API must respond with Cache-Control: no-store or the caller must add a unique query parameter to bust the cache.

Visualforce remoting and Lightning data services

Historically, Visualforce remoting used XMLHttpRequest under the covers, defaulting to POST but invoking read-only Apex methods. Modern Lightning Web Components use lightning/uiRecordApi (LDS) for record reads, which under the covers issues GET requests to the User Interface API. Custom @AuraEnabled methods marked cacheable use GET semantics; non-cacheable ones use POST.

Callout limits that apply to every GET

Each Apex transaction can make 100 outbound callouts (synchronous + async combined). Each callout has a 120-second timeout and a 6-MB response size limit. Long-running GETs that exceed the timeout must move to async Apex (Queueable) or to platform-event-driven patterns. Bulk GETs against the same external system should batch through a queue with rate-limiting awareness; the platform does not throttle the caller, but the called API often does.

§ 03

Make a GET callout from Apex

Setting up a GET callout takes three Apex statements once the Named Credential is in place. The rest is parsing the response.

  1. Create a Named Credential

    Setup, Named Credentials, New. Enter the URL, choose the authentication protocol, and save. The Named Credential gets a unique name (e.g., StripeApi).

  2. Build the HttpRequest in Apex

    HttpRequest req = new HttpRequest(); req.setEndpoint('callout:StripeApi/customers/cus_abc'); req.setMethod('GET'); The callout: protocol references the Named Credential and injects authentication automatically.

  3. Send and capture the response

    Http http = new Http(); HttpResponse res = http.send(req); String body = res.getBody(); Integer status = res.getStatusCode();

  4. Parse the JSON

    Use JSON.deserialize or JSON.deserializeUntyped to convert the body into an Apex object or a Map. Handle missing fields and null values explicitly.

  5. Handle errors and retry transient failures

    Check status code; 2xx is success, 4xx is a client error (do not retry), 5xx is a server error (retry with backoff). Log failures to a custom Object or a logging framework.

Mandatory fields
Endpointrequired

The URL or Named Credential reference the request targets.

Methodrequired

GET; setMethod is optional but should be explicit.

Authenticationrequired

Handled by Named Credential or set explicitly with setHeader('Authorization', 'Bearer ...').

Timeoutrequired

Defaults to 10 seconds; max 120. Set via setTimeout(120000) for slow endpoints.

Gotchas
  • Apex callouts cannot be made after a DML statement in the same transaction. Make the GET first or move the DML to an async context.
  • Hard-coding endpoint URLs in Apex breaks across sandbox, production, and packaged deployments. Use Named Credentials instead.
  • The 6-MB response limit is hard. APIs returning large payloads must paginate; the Apex code must follow the next-page links.
  • Query-string parameters with special characters need EncodingUtil.urlEncode. Skipping the encode leads to silent integration failures when users have apostrophes or spaces in input.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Get Request.

Keep learning

Hands-on resources to go deeper on Get Request.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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 a GET Request do?

Q2. Where do you use GET requests in Salesforce?

Q3. What other HTTP verbs are commonly used?

§

Discussion

Loading…

Loading discussion…