Study material for Integration

1. Salesforce API
 There are many types of APIs like REST API, SOAP API, Bulk API, and Streaming API.
 Together they make up the Salesforce data APIs.
REST API
 REST API is a simple and powerful web service based on RESTful principles.
 REST defines a set of architectural principles by which you can design Web services that focus
on a system's resources, including how resource states are addressed and transferred over
HTTP by a wide range of clients written in different languages.
 REST API supports both XML and JSON.
 Because REST API has a lightweight request and response framework and is easy to use, it’s
great for writing mobile and web apps.
 In layman language, Representational state transfer (REST) or RESTful web services is a way of
providing interoperability between computer systems on the Internet. REST-compliant Web
services allow requesting systems to access and manipulate textual representations of Web
resources using a uniform and predefined set of stateless (In computing, a stateless protocol is
a communications protocol in which no information is retained by either sender or receiver.”
operations.
When to use:
 REST API provides a powerful, convenient, and simple REST-based web services interface for
interacting with Salesforce.
 Its advantages include ease of integration and development, and it’s an excellent choice of
technology for use with mobile applications and web projects.
 However, if you have many records to process, consider using Bulk API, which is based on REST
principles and optimized for large sets of data.
 Apex REST API when you want to expose your Apex classes and methods so that external
applications can access your code through REST architecture.
 Apex REST API supports both OAuth 2.0 and Session ID for authorization.
Bulk API
 Bulk API is a specialized RESTful API for loading and querying lots of data at once.
 By lots, we mean 50,000 records or more.
 Bulk API is asynchronous, meaning that you can submit a request and come back later for the
results.
 There are two versions of Bulk API (1.0 and 2.0). Bulk API 2.0 is easier to use.
 Bulk API is great for performing tasks that involve lots of records, such as loading data into your
org for the first time.

2. SOAP API
 It stands for Simple Object Access Protocol
 It is a messaging protocol that allows programs that run on disparate operating systems (such as
Windows and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and its Extensible
Markup Language (XML).
 It is a protocol specification for exchanging structured information.
 It uses a Web Services Description Language (WSDL) file to rigorously define the parameters for
accessing data through the API.
 SOAP API supports XML only.
 Most of the SOAP API functionality is also available through REST API.
 Because SOAP API uses the WSDL file as a formal contract between the API and consumer, it’s
great for writing server-to-server integrations.
When to use:
 SOAP API provides a powerful, convenient, and simple SOAP-based web services interface for
interacting with Salesforce.
 You can use SOAP API to create, retrieve, update, or delete records.
 You can also use SOAP API to perform searches and much more.
 Use SOAP API in any language that supports web services.
 Use Apex SOAP API when you want to expose Apex methods as SOAP web service APIs so that
external applications can access your code through SOAP.
 Apex SOAP API supports both OAuth 2.0 and Session ID for authorization.
Streaming API:
 Streaming API is a specialized API for setting up notifications that trigger when changes are
made to your data.
 It uses a publish-subscribe, or pub/sub, model in which users can subscribe to channels that
broadcast certain types of data changes.
 The pub/sub model reduces the number of API requests by eliminating the need for polling.
Streaming API is great for writing apps that would otherwise need to frequently poll for changes.

3. API Access and Authentication:
 To access Salesforce APIs, you should have API enabled permission and you can integrate.
 All API calls, except for the SOAP API login() call, require authentication.
 You can either use one of the supported OAuth flows or authenticate with a session ID retrieved
from the SOAP API login() call.
API Limits
 There are two types of API limits.
 Concurrent limits cap the number of long-running calls (20 seconds or longer) that are running at
one time.
 Total limits cap the number of calls made within a rolling 24-hour period.
 For a sandbox org, it’s 25 long-running calls and for a Developer Edition org, the limit is five long-
running calls at once.
 There are several ways to check remaining API calls:
1. API Usage box
Setup--- System Overview--- API Usage
Note:
System Overview: give all view like API usage, custom object, Classes etc.
 To setup API Usage Notifications
Setup---- API Usage Notifications

4. Use REST API
REST Resources and Methods:
 A REST resource is an abstraction of a piece of information or an action, such as a single data
record, a collection of records, or a query.
 Each resource in REST API is identified by a named Uniform Resource Identifier (URI) and is
accessed using standard HTTP methods (HEAD, GET, POST, PATCH, DELETE).
 URI is is a string of characters used to identify a resource.
 REST API is based on the usage of resources, their URIs, and the links between them.
 A REST request consists of four components: a resource URI, an HTTP method, request
headers, and a request body.
 Request headers specify metadata for the request. The request body specifies data for the
request, when necessary.
Note:
Workbench:
 Workbench is a suite of tools for interacting with your Salesforce org through the API.
 URL is https://workbench.developerforce.com/login.php
 Because you can make REST requests from any HTTP sender, there are plenty of other tools
available for you to use (for example, check out cURL or Postman).

5. Apex REST Callouts
 An Apex callout enables you to tightly integrate your Apex code with an external service.
 The callout makes a call to an external web service or sends an HTTP request from Apex code,
and then receives the response.
 Apex callouts come in two flavors.
1. Web service callouts to SOAP web services use XML, and typically require a WSDL
document for code generation.
2. HTTP callouts to services typically use REST with JSON.
 These two types of callouts are similar in terms of sending a request to a service and receiving a
response.
 But while WSDL-based callouts apply to SOAP Web services, HTTP callouts can be used with
any HTTP service, either SOAP or REST.
Note:
 Whenever possible, use an HTTP service.
 These services are typically easier to interact w ith, require much less code, and utilize easily readable JSON.
Authorize Endpoint Addresses
HTTP and Callout Basics:
 REST callouts are based on HTTP.
 Each callout request is associated with an HTTP method and an endpoint.
 The HTTP method indicates what type of action is desired.

6.  When the server processes the request, it sends a status code in the response.
 The status code indicates whether the request was processed successfully or whether errors
were encountered.
 If the request is successful, the server sends a status code of 200.
 You’ve probably seen some other status codes, such as 404 for file not found or 500 for an
internal server error.
HTTP classes:
These classes expose the HTTP request and response functionality.
1. Http Class: Use this class to initiate an HTTP request and response.
2. HttpRequest Class: Use this class to programmatically create HTTP requests like GET,
POST, PUT, and DELETE.
3. HttpResponse Class: Use this class to handle the HTTP response returned by HTTP.
 The HttpRequest and HttpResponse classes support the following elements.
a. HttpRequest
 HTTP request types, such as GET, POST, PUT, DELETE, TRACE, CONNECT, HEAD,
and OPTIONS
 Request headers if needed
 Read and connection timeouts
 Redirects if needed
 Content of the message body
b. HttpResponse
 The HTTP status code
 Response headers if needed
 Content of the response body
 This example makes an HTTP GET request to the external server passed to the
getCalloutResponseContents method in the url parameter.
This example also accesses the body of the returned response.
 The previous example runs synchronously, meaning no further processing happens until the
external web service returns a response.
 Alternatively, you can use the @future annotation to make the callout run asynchronously.

7. Named Credentials as Callout Endpoints:
 A named credential specifies the URL of a callout endpoint and its required authentication
parameters in one definition.
 Salesforce manages all authentication for Apex callouts that specify a named credential as the
callout endpoint so that your code doesn’t have to.
 You can also skip remote site settings, which are otherwise required for callouts to external sites,
for the site defined in the named credential.
 By separating the endpoint URL and authentication from the callout definition, named credentials
make callouts easier to maintain.
 For example, if an endpoint URL changes, you update only the named credential.
 All callouts that reference the named credential simply continue to work.
 If you have multiple orgs, you can create a named credential with the same name but with a
different endpoint URL in each org.
 You can then package and deploy—on all the orgs—one callout definition that references the
shared name of those named credentials.
 If you have multiple orgs, you can create a named credential with the same name but with a
different endpoint URL in each org. You can then package and deploy—on all the orgs—one
callout definition that references the shared name of those named credentials. For example, the
named credential in each org can have a different endpoint URL to accommodate differences in
development and production environments. If an Apex callout specifies the shared name of those
named credentials, the Apex class that defines the callout can be packaged and deployed on all
those orgs without programmatically checking the environment.
 To reference a named credential from a callout definition, use the named credential URL. A
named credential URL contains the scheme callout:, the name of the named credential, and an
optional path. For example: callout:My_Named_Credential/some_path.
 You can append a query string to a named credential URL. Use a question mark (?) as the
separator between the named credential URL and the query string. For example:
callout:My_Named_Credential/some_path?format=json.

8.  In contrast, let’s see what the Apex code looks like without a named credential.
 Notice that the code becomes more complex to handle authentication, even if we stick with basic
password authentication.
 Coding OAuth is even more complex and is an ideal use case for named credentials.

9. Custom Headers and Bodies of Apex Callouts That Use Named Credentials:
 Salesforce generates a standard authorization header for each callout to a named-credential-
defined endpoint, but you can disable this option.
 Your Apex code can also use merge fields to construct each callout’s HTTP header and body.
 This flexibility enables you to use named credentials in special situations.
 For example, some remote endpoints require security tokens or encrypted credentials in request
headers.
 Some remote endpoints expect usernames and passwords in XML or JSON message bodies.
 Customize the callout headers and bodies as needed.
 The Salesforce admin must set up the named credential to allow Apex code to construct headers
or use merge fields in HTTP headers or bodies.
 The following table describes these callout options for the named credential.

10. Merge Fields for Apex Callouts That Use Named Credentials:
 To construct the HTTP headers and request bodies of callouts to endpoints that are specified as
named credentials, use these merge fields in your Apex code.
Merge Field Description
1. {!$Credential.Username}
{!$Credential.Password}

11. 2. {!$Credential.OAuthToken}
3. {!$Credential.AuthorizationMethod
4. {!$Credential.AuthorizationHeaderValue}
5. {!$Credential.OAuthConsumerKey}
Note: