Skip to content
SteveTechArcSteveTechArc Courses

The Six Lines of a Callout

Module 2 of 8 in the chapter Salesforce as an API Consumer, chapter 9 of the Integration Architect course. Each module stands on its own. Previous: Leaving Salesforce · Next: Dealing With the Answer

The question this module answers: What does it actually take for Apex to call another system, and which options on the call should an architect know?

Here’s the super secret advanced code you need to know as an integration architect. It’s six lines. Whether you write the code yourself or run a team that does, you should know these six lines and how they work with each other.

The Six Lines

Section titled “The Six Lines”

Steve Trucking wants to ask Redrock for the status of a shipment:

Http http = new Http();                                           // 1
HttpRequest req = new HttpRequest();                              // 2
req.setEndpoint('callout:Redrock_Status/v1/shipments/D-1042');    // 3
req.setMethod('GET');                                             // 4
HttpResponse res = http.send(req);                                // 5
if (res.getStatusCode() == 200) { String body = res.getBody(); }  // 6
  1. Create the Http object. It’s the thing that does the sending.
  2. Create the request. Everything about the ask goes on it.
  3. Say where. The endpoint. With a named credential, it starts with callout: and the credential’s name, and the rest is the path. No address and no secret in the code.
  4. Say the verb. GET, POST, PATCH, PUT, DELETE, the verbs from chapter 3.
  5. Send it. That’s the callout. The code stops here and waits for the answer.
  6. Check what happened. You sent it. Now what happened? You don’t know until you check the status code. Then, and only then, read the body.

That’s it. That’s all it takes to make a callout. Everything else in this chapter is about doing these six lines well.

The six lines of a callout The six lines of a callout, as three moves. In Steve Trucking's Apex: build the ask, lines 1 to 4, the Http object, the HttpRequest, the endpoint callout:Redrock_Status and the verb. Then send it, line 5, http.send, in navy and tagged the callout: the code waits here. It goes as a GET, through the named credential, to Redrock's system, on Redrock's side, which answers with a status and a body. The answer comes back, 200 and a body, to check the answer, line 6: the status code first, then the body. Underneath: you sent it; now what happened? You don't know until you check the status. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-INT-SC-02", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} IN STEVE TRUCKING'S APEX REDROCK'S SIDE Build the ask lines 1–4: Http, HttpRequest, the endpoint callout:Redrock_Status, the verb Send it line 5: http.send(req); the code waits here the callout Redrock's system answers with a status and a body Check the answer line 6: the status code first, then the body ready GET 200 and a body You sent it. Now what happened? You don't know until you check the status. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Six lines: build the ask, send it, check the answer.

What Else Goes on the Request

Section titled “What Else Goes on the Request”

The six lines are the bones. Around them, the request can carry more, and each piece is a decision.

A body, sometimes. A POST, PUT or PATCH sends data, so it has a body: req.setBody(...). A GET doesn’t. Do I put a body on a GET? No. A GET only has the address and the headers.

Headers. The two you’ll set most are the content type, so the other system knows whether you’re sending JSON or XML, and the authorization. With a named credential, you don’t set the authorization at all. Salesforce “manages all authentication for Apex callouts that specify a named credential” (chapter 4). That includes the dull, important work every client has to do: when a token expires, go back, sign in again, and try with the new one. In my video on the client and server, I said the client “needs to be prepared at any time for a session expiration.” With a named credential, Salesforce is prepared for you.

A timeout. How long will Salesforce wait? The default is 10 seconds, and you can set anything from 1 millisecond to 120,000, two minutes (Callout Limits and Limitations (opens in a new tab), Apex Developer Guide, checked 2026-10-31). Read the fine print: it’s the time to wait for the connection and for the answer to start; once data is flowing, the connection stays open until it’s done (HttpRequest Class (opens in a new tab), Apex Reference Guide, checked 2026-10-31). Set it on purpose, from what you know about the other system, not by leaving the default. Module 4 is about why.

Compression. req.setCompressed(true) zips the body before it leaves, in gzip, and if the answer comes back compressed, getBody() unzips it for you (same page). It costs a little time at each end. On one implementation, we were sending big text payloads between servers far apart, broken into lots of network packets. Compressing them took them down to about one-tenth of their size, and they shot across. So: small payloads, compression may not be worth it. Big payloads, it might be worth a lot. The other end has to accept it, so it goes in the contract.

A client certificate. Some systems want proof from the caller as well as from themselves: two-way TLS. setClientCertificateName names the certificate to present. Chapter 13 is about why and how; here, just know the request can carry one.

What About SOAP?

Section titled “What About SOAP?”

Salesforce can still call a SOAP service. You bring in the other system’s WSDL, Salesforce generates Apex classes from it, and you call a method on them. You’ll probably never do it, unless the other end is a legacy system. It may still appear on the exam, so chapter 17 (coming soon) covers it with the rest of SOAP’s story.

Test knowledge. Know the six lines by their classes and calls: Http, HttpRequest with setEndpoint and setMethod, Http.send, and HttpResponse with getStatusCode and getBody. Know that the endpoint must be approved first, with a named credential (callout:) or, the older way, a remote site setting. Know that a GET has no body, and that the default timeout is 10 seconds, up to 120 seconds.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • The named credential every callout uses. callout: in every endpoint; no address and no secret in the code.
  • The timeout for each call, from what you know about the other system, not the default.
  • Compression, for big payloads, written into the contract so both ends agree.
  • Whether the other system wants a client certificate, and who looks after it (chapter 13).

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.