Early Salesforce integrations (2018)

In 2018 I wanted to understand how Salesforce talks to the outside world without a managed package or middleware: how an Apex class builds an HTTP request, how it authenticates, and what the org has to allow before a callout can leave it. The best way I knew was to wire Salesforce to a few real APIs myself.

Three small integrations, each one Apex class plus one Visualforce page, written in the Developer Console between August and October 2018:

• Twitter: a page with one button that posts a status through Twitter's REST API v1.1. Twitter required OAuth 1.0a, so the Apex class builds the signature itself.
• Twilio SMS: a "Send Text Message" page with a mobile number and a message field. The controller posts to Twilio's REST API with HTTP Basic auth and reads the account details and sender number from a hierarchy custom setting.
• Org to org: a contact form that saves a Contact, then a @future callout logs in to a second Salesforce org with the OAuth username-password flow and calls a custom Apex REST endpoint there, which stores the id in a custom object.

How it works

Each flow is the same shape: a Visualforce page calls an Apex controller, the controller builds an HttpRequest, and a Remote Site Setting allows the callout to the external host.

The Twitter class is the interesting one. It signs the request the long way: a random nonce, a Unix timestamp, the parameters sorted into a signature base string, an HMAC-SHA1 with Crypto.generateMac, Base64, and finally an Authorization: OAuth … header. Writing that by hand taught me exactly what an OAuth 1.0a signature is. The Twilio controller form-encodes To, Body and From, sends them with Basic auth, and turns Twilio's JSON response into a page message.

These are historical. The Twitter v1.1 endpoint has since been replaced by X's v2 API, and the Twilio code calls a legacy SMS resource. The bigger lesson is where the credentials lived: in a custom setting, or in the class itself. That is why I don't link these repos: their history still holds credentials that have been retired.

Today I would build all three with a Named Credential and an External Credential. Salesforce stores the endpoint and the secrets, applies OAuth or Basic auth for you, and the Apex code only references callout:<Name>, so no key sits in code, in a custom setting users can read, or in a debug log. No Remote Site Setting is needed, and a test class with an HttpCalloutMock covers the response handling.

Stack: Apex, Visualforce, HTTP callouts, OAuth 1.0a, Twilio REST API, Salesforce REST API.

Status and links

Completed and not maintained: none of the three is deployed or demoed live. For how I handle authentication in Salesforce now, see the OAuth day of my Salesforce Headless 360 series (coming soon).