Skip to content
Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryWWeb Service
DevelopmentAdvanced

Web Service

A Web Service in Salesforce is an API endpoint (REST, SOAP, or GraphQL) that enables programmatic communication between Salesforce and external systems.

§ 01

Definition

A Web Service in Salesforce is an API endpoint (REST, SOAP, or GraphQL) that enables programmatic communication between Salesforce and external systems. Salesforce both provides Web Services (the platform standard APIs that external systems consume) and consumes Web Services (external endpoints that Apex code calls from inside the org). The bidirectional nature is what makes Salesforce a participant in larger integration architectures rather than an isolated CRM silo.

The Salesforce-provided side includes REST API, SOAP API, Bulk API, Streaming API, Connect REST API, GraphQL API, Metadata API, and Tooling API. The Salesforce-consumed side includes Apex HTTP callouts to any external REST endpoint, named credentials for managing authentication, and platform integrations like Salesforce Connect for federated data access. Beyond the standard platform APIs, developers can expose custom Apex methods as REST or SOAP Web Services through the @RestResource and webservice keywords, turning specific business logic into reusable integration points.

§ 02

Web Services on the Salesforce platform: inbound, outbound, authentication, and operations

Inbound vs outbound Web Services on the Salesforce platform

Web Services on Salesforce go in two directions. Inbound services are endpoints external systems call into Salesforce: REST API for record CRUD, SOAP API for legacy callers, Bulk API for large data loads, Connect REST API for Chatter and CMS, custom Apex REST services for org-specific business logic. Outbound services are external endpoints Salesforce calls out to: Apex HTTPCallout to any REST endpoint, Apex Web Service Callout to any SOAP endpoint, Platform Events that push messages to subscribed external systems, and Salesforce Connect that federates external data through external objects. The directional distinction matters for security and authentication: inbound services authenticate the external caller through OAuth or named credentials; outbound services authenticate Salesforce through credentials stored on the org side.

Standard platform Web Services on Salesforce

Salesforce ships several standard Web Services that external systems integrate against. REST API is the default for most modern integrations: JSON, OAuth, versioned URLs (v59.0). SOAP API is the original XML-based interface still used by legacy callers and a few feature-specific use cases. Bulk API and Bulk API 2.0 handle very large data loads through asynchronous jobs. Streaming API and the newer Pub/Sub API push events to subscribed clients through CometD or gRPC. Metadata API moves metadata between orgs for deployments. Connect REST API exposes Chatter, Communities, and CMS features. GraphQL API offers a single-endpoint, flexible-field-selection alternative for query-heavy use cases. Each service has its own quirks, rate limits, and best fit; choosing the right one is the most impactful architectural decision in any Salesforce integration.

Custom Apex Web Services and the @RestResource annotation

Developers can expose custom Apex methods as Web Services to external callers. For REST, the @RestResource annotation on an Apex class registers it at a custom URL path under /services/apexrest. Methods inside the class annotated with @HttpGet, @HttpPost, @HttpPut, @HttpDelete handle the corresponding HTTP verbs. The platform handles authentication (OAuth or session id), authorization (the calling user permissions apply), and JSON serialization automatically. For SOAP, the older webservice keyword on an Apex method exposes it through a custom WSDL. Both patterns turn org-specific business logic (a custom record-creation flow, a batch lookup against custom criteria, an aggregation that combines multiple objects) into reusable integration points that external systems can call without knowing the underlying Salesforce data model.

Authentication patterns: OAuth, Named Credentials, JWT

Every Web Service call (inbound or outbound) needs authentication. Inbound services authenticate the external caller through OAuth 2.0 against a Connected App configured in the target Salesforce org. The caller obtains an access token through one of several OAuth flows (Web Server, JWT Bearer, Client Credentials) and sends it in the Authorization header of every API call. Outbound services authenticate Salesforce through Named Credentials, which store the endpoint URL plus the authentication details (username and password, OAuth token, certificate) in a managed configuration that Apex callouts reference. JWT Bearer flow is the modern preferred pattern for server-to-server integrations because it avoids storing long-lived credentials on either side; the integration uses a signed JWT that the target system verifies against a public key.

Rate limits, governor limits, and operational concerns

Web Services on Salesforce share rate limits with the rest of the platform. Each org has a daily API request limit that scales with the number of paid Salesforce licenses (typically tens of thousands per day for Enterprise Edition). Inbound API calls count against this limit. Outbound Apex callouts count against per-transaction limits (100 callouts max per Apex transaction) plus the per-callout timeout (60 seconds max for synchronous, longer with Continuation). The Bulk API has its own job-and-batch quotas separate from the daily request limit. Hitting any of these limits returns an error and blocks subsequent calls until the limit resets. Mature integrations monitor usage proactively and throttle at 70 to 80 percent of the limit to leave headroom for unexpected bursts.

Web Service versioning and the upgrade lifecycle

Every Salesforce-provided Web Service includes a version number in the URL or WSDL (v59.0 for the Winter 24 release). New API versions ship with every Salesforce release. Older API versions remain supported indefinitely so customer integrations do not break on every Salesforce upgrade. Best practice for inbound integrations is to pin each integration to a specific API version and bump it on a controlled schedule after testing. For custom Apex Web Services exposed by an org, the Apex class itself has an API Version that controls platform behavior; consumers do not see this version directly. Read the Salesforce API behavior compatibility guide before any version bump; behavioral differences between versions can surprise integrations that did not test the upgrade in a sandbox.

§ 03

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. 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. 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. 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. 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.

Gotchas
  • Inbound and outbound Web Services have different authentication patterns. Inbound uses OAuth against a Connected App; outbound uses Named Credentials. Mixing them up produces auth failures that look like wrong code but are really wrong configuration.
  • Salesforce-provided Web Services have versioned URLs (v59.0). Pin each integration to a specific version; floating to the latest version breaks the integration the moment Salesforce ships a behavior change.
  • Outbound callouts count against per-transaction limits (100 max per transaction, 60 second timeout). High-volume outbound integrations need careful batching and asynchronous execution.
  • Custom Apex REST services run as the calling user. Field-level security, sharing rules, and profile permissions all apply. A user with limited access who calls the service sees limited results, even if the Apex code does not filter.
  • Named Credentials store the endpoint URL plus authentication. Changing the URL requires updating the Named Credential, not the Apex code; Apex code references the Named Credential by name.
§

Trust & references

Official documentation

Straight from the source - Salesforce's reference material on Web Service.

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 is a Web Service?

Q2. What protocols does Salesforce support?

Q3. Does Salesforce only provide services?

§

Discussion

Loading…

Loading discussion…