Salesforce provides a number of APIs to access and manipulate records in its own objects that belong to applications such as CRM; these APIs are also extended to support Custom Objects created by admins or provided by packages installed in the subscriber org. Salesforce dedicates a huge amount of its own and community-driven documentation resources you can reference when educating partners and customer developers on the use of these APIs. Thus, it is important that your application works well with these APIs.

Platform APIs are enabled for Enterprise Edition orgs and above, though if you have a need to consume them in Professional or Group Edition orgs, Salesforce can provide a Partner API token (following the completion of a security review) to enable their use; this is unique to your application and so does not provide access for code other than yours.

Typically, unless you are developing an off-platform utility or integration to accompany your application, you may not find your application consuming these APIs at all, though there are some you might want to consider, highlighted in the following bullets. Keep in mind, however, that if you do, in addition to the Partner API token, the subscriber org's daily API limit will also be consumed; hence, ensure that your usage is as network-optimal as possible.

Enterprise-level customers often have complex integration requirements both on- and off-platform; typically, Salesforce utilizes the SOAP and REST technologies to make these APIs available to any number of platforms and languages such as Java and Microsoft .NET. In Chapter 9, User Interfaces with Lightning Framework, we will discuss how you can extend the features of the platform's data-orientated APIs with your own more application-process-orientated APIs.

The following list details some of the main APIs that may be of use to your Enterprise-level customers wishing to develop solutions around your application:

• Enterprise API: This SOAP API is dynamically generated based on the objects present at the time in the subscriber org, meaning that any tool (such as data-mapping tools) or developer consuming it will find the information it exposes familiar and easy to access. One downside, however, is that this can end up being quite a large API to work with, as Enterprise customer orgs often have hundreds of objects and fields in them.
• Partner API: This is also a SOAP API; unlike the Enterprise API, it provides a more generic CRUD-based API to access the record in the subscriber org. Its name can be a bit misleading, as there is no restriction on non-partners using it, and, as it is lighter than the Enterprise API, it's often the first choice.
• REST API: This provides another CRUD style API, similar to the Partner API, but, in this case, it is based on the more popular REST technology standard. It's often preferred when building mobile applications and is also fast becoming popular as the default API for Java and .NET.
• User Interface API: This provides a singular API that provides mobile applications or custom UIs not built on the Salesforce platform with a response that not only contains record data pre-filtered by the user's security access but also metadata such as layouts and applicable actions for the requesting device type.
• Metadata API and Tooling API: These SOAP APIs provide a means to automate many of the tasks performed under the Setup menu and those performed by developers when editing code. While these might not be of direct interest to those integrating with your application, as many of these tasks are performed initially and then only rarely, it might be something to consider using in tools you want to provide to keep the implementation times of your application low.
• Streaming API: This API utilizes an HTTP long polling protocol known as the Bayeux protocol to allow callers to monitor in near real time and record activity in Salesforce. This API can be used on a page to monitor race data as it arrives and display it to the user in near real time. A number of platform features support streaming, Push Topics, Platform Events, and Change Data Capture.
  • Push Topics allow you to configure criteria on standard and Custom Objects that, when met, will send an event to a specific channel.
  • Platform Events allow you to create an event, much like a Custom Object, that has specific fields describing the event payload. Using various platform features, such as Apex, Process Builder, Flow, and Lightning, you can publish events yourself and subscribe to those created by others. I will be covering Platform Events in more detail in a later chapter.
  • Change Data Capture (CDC) sends events to the stream whenever users create, update, or delete data. It can be enabled for Custom Objects and some Standard objects. 
• Replication API: Sometimes it is not possible or desirable to migrate all data into Salesforce through Custom Objects. In some cases, this migration is too complex or cost-prohibitive. This REST and Apex API allows replication solutions to determine for a given period of time which records for a given object have been created, updated, or deleted.
• Bulk API: This REST-based API allows the import and export of large numbers of records in CSV or XML format up to 10 MB in size per batch job.
• Async SOQL: This REST-based API allows you to process billions of records stored in Big Objects, Field Audit Trail, or Event Monitoring objects and extract aggregated subsets of that data into Custom Objects for more direct processing and filtering. For more information, see this Salesforce help topic: https://developer.salesforce.com/docs/atlas.en-us.bigobjects.meta/bigobjects/async_query_examples.htm.