How Does Pulsar use API Calls?
- Carla Locke
- geevall
What is an API call?
An API call is a request or query to the Salesforce platform for either data or metadata. Third-party applications, like Pulsar, must use API calls to get the required data/metadata from Salesforce. For more information about API calls, refer to API Call Basics.
Why does the number of API Calls matter?
Depending on your Salesforce licensing agreement, you may have a limit on the number of API calls you can use per day. Hitting your API call limit can disrupt business processes. For more information about how Salesforce allocates resources, refer to Salesforce Features and Edition Allocations.
Salesforce could throttle your requests/responses
Salesforce servers, in essence are shared resources across their customer base. Salesforce strives to be fair so everyone gets the data they request in a timely manner. If you make a large number of simultaneous requests or request a large amount of data, Salesforce could throttle your request by sending a lower number of records per response. Throttling results in increased API calls. For more details about the API limits, refer to API Request Limits and Allocations.
How does Pulsar use API calls?
Pulsar is a client application for Salesforce. Since Pulsar is designed to function completely offline, it must download the required data and metadata from Salesforce to store on the user’s device. API calls are used during the request for data from Salesforce.
When does Pulsar use API calls?
In Pulsar, each time you request data or metadata from Salesforce, API calls are used.
Pulsar uses API calls under the following circumstances:
Initial Sync - The initial sync process is a request for all of the Salesforce data that you want to access in Pulsar, plus the metadata that defines how Pulsar will display the data. Many API calls are used in this large request for data.
Catch-Up Sync - The catch-up sync requests only the data that has changed since the last successful sync. Typically, this does not include metadata. Some API calls are used during the catch-up sync, but not as many as an initial sync.
Local Data Push - Local data pushes occur when new or updated data is sent to the Salesforce servers from the user’s device. Metadata is not transferred in this process. This process consumes some API calls.
Refresh Settings - When Refresh Settings is pushed or forced via an automatic process, metadata is updated and requires API calls.
Other processes - Other processes, such as the Salesforce license check, may also use a small number of API calls.
Can you calculate the number of API Calls that Pulsar will use?
Salesforce sends between 200 and 2000 records in each API Call. The number of records depends on the amount of data in each record. For instance, you may request 10,000 records which each contain a short text phrase and only use 5 API Calls (10,000 records / 2000 records per API Call). Alternatively, you may request 10,000 records containing images, documents, or long text blocks and use 50 API calls (10,000 records / 200 records per API call). This is because short text fields contain small amounts of data, while images, documents, and large text fields contain larger amounts of data. To complicate matters further, requesting records from narrow tables with only a few fields versus large tables with many fields may cause Salesforce to throttle the request and send back a smaller number of records in each API call. Throttling can happen for other reasons, too, determined by Salesforce.
For these reasons, it is difficult to calculate the actual number of API calls that will be used by Pulsar.
How can I see the number of API calls used in Pulsar?
We recommend that you test your settings in your full sandbox, then look at the System Overview screen (under the Settings/Gear icon on the browser) to see the number of API calls used during your test. To learn how to view your API limits, refer to this video: Understanding API Limits | Salesforce Platform.
How to reduce the number of API calls in Pulsar
Now that you understand how Pulsar uses API calls, you can make adjustments to reduce the number of API calls you use.
Reducing the amount of synced data will reduce the number of API calls used by Pulsar.
Use Salesforce settings to reduce the sync data
You can use Salesforce permissions and sharing settings to filter the data available to each user. This will reduce the overall amount of data that can be synced in Pulsar. An example is limiting the user to accessing only records for accounts contained in the user’s territory. Alternatively, you could use Pulsar settings to apply sync filters to download data that is pertinent to the user.
Use Pulsar Settings to reduce the sync data
Another way to reduce your API call usage is to reduce the number of records maintained on your user’s device. You can use the data sync settings in Pulsar Settings to filter the data by job role, region, account, or other criteria. You can also use Pulsar Settings to reduce the number of times the sync process occurs, or the amount of data included in a sync. For more information, see Data Sync Settings. Here are some examples of Pulsar settings you could use:
Pulsar Sync Object List - pulsar.sync.objects - Limit the objects you want to sync to Pulsar.
Pulsar Sync Objects - Relationship Directives - pulsar.sync.relationship.directives - Limit the objects you want to sync by their data relationships.
Object Filter Limit - pulsar.sync.initialFilterLimit - Limit the number of records fetched by each object.
Auto Sync Time Interval - pulsar.sync.autoSyncIntervalMinutes - Limit the number of times Auto Sync runs.
Sync Data Filter using a “Where” Clause - pulsar.<sobject type>.syncFilter - Limit the records which are synced for each object using a SOQL format where clause.
Disable syncing listviews for certain object types - pulsar.sync.listViews.disabledObjects - Allows Pulsar to skip syncing listviews for certain objects. Useful when there are many listviews in an object.
Enable Composite Graph API - pulsar.sync.enableCompositeGraphAPI - Sends as many local changes as possible in a single request to the server. Otherwise, each change is processed in a separate request.