Building or consuming a Salesforce Web Service end to end

Building or consuming a Web Service on Salesforce is a sequence of decisions: pick the right API (inbound versus outbound, REST versus SOAP versus GraphQL), configure authentication (OAuth, Named Credentials, JWT Bearer), implement the actual integration code, and operationalize for production. The four-step routine below covers the standard pattern. Skipping any step produces integrations that work in sandbox and break in production, usually around authentication or rate limiting.

1. 1
   Pick the right Web Service for the workload

   Identify whether the integration is inbound (external system calls Salesforce) or outbound (Salesforce calls external). For inbound, pick REST API for general-purpose CRUD on small to medium volumes, Bulk API for large data loads, Streaming or Pub/Sub for real-time push, Connect REST for Chatter, GraphQL for query-heavy use cases, or custom Apex REST for org-specific business logic. For outbound, pick Apex HTTPCallout for REST endpoints, Apex Web Service Callout for SOAP endpoints, Platform Events to push messages, Salesforce Connect for federated data. Document the choice and rationale in the integration design document.

2. 2
   Configure authentication

   For inbound services, create a Connected App in Salesforce Setup with the right OAuth scopes and the right OAuth flow (Web Server for human-initiated, JWT Bearer for server-to-server with certificate, Client Credentials for newer server-to-server). Provide the Consumer Key and Consumer Secret to the external integration team. For outbound services, configure a Named Credential in Salesforce Setup with the external endpoint URL plus the authentication details (username and password, OAuth, certificate). Reference the Named Credential by name in Apex code rather than hardcoding credentials. Test the authentication flow with a smoke-test call before implementing the business logic.

3. 3
   Implement the integration code

   For inbound custom services, write an Apex class with @RestResource and methods annotated @HttpGet, @HttpPost, @HttpPut, @HttpDelete. Use RestRequest and RestResponse to read input and write output. Serialize results as JSON. Add Apex test methods that exercise the service with sample payloads. For outbound services, write Apex code that builds an HttpRequest, sets the endpoint and authentication via the Named Credential, sends the request, and parses the response. Handle errors explicitly: timeouts, HTTP 4xx and 5xx, JSON parse errors. Add retry-with-exponential-backoff for transient failures.

4. 4
   Operationalize for production

   Add monitoring to track Web Service usage: daily API request count, per-integration response time, error rate per endpoint. Set alerts on usage above 80 percent of any limit. Document the integration in the org API runbook: which service, which authentication, which external counterpart, who owns it. Rotate credentials on a schedule defined by the org security policy. Build a rollback plan in case the integration starts failing in production; for outbound integrations, that often means temporarily disabling the Apex code or switching to a fallback endpoint. Treat each Web Service as a tier-1 production component if it carries business-critical traffic.