---
schema_version: "1"
id: b1e7b3ea8eb58ab9e8b77bddd6a08780cf45979f1af21751619e868773764b48
title: Loading Data from the API
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/platform/salesforce-large-data-volumes-bp/guides/cce/ldv-deployments/ldv-deployments-best-practices-api-loading-data.md
canonical_url: https://developer.salesforce.com/docs/platform/salesforce-large-data-volumes-bp/guide/ldv-deployments-best-practices-api-loading-data.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 27a63600d7b6d796e6e4b7193ed1c94ac6d13f6468e7a0870102ff77e4b7bc7d
products:
  - Best Practices for Deployments with Large Data Volumes
  - Platform Developer Content
---

# Loading Data from the API

|Goal|Best Practice|
|----|-------------|
|Improving performance|Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0 to successfully prepare, execute, and manage an *asynchronous* workflow that makes use of the Bulk framework. Jobs with fewer than 2,000 records should involve “bulkified” *synchronous* calls in REST (for example, Composite) or SOAP.|
|Using the most efficient operations|<ul><li>Use the fastest operation possible—`insert()` is fastest, update() is next, and upsert() is next after that. If possible, also break upsert() into two operations: create() and update().</li><li>Ensure that data is clean before loading when using the Bulk API 2.0. Errors in batches trigger single-row processing for that batch, and that processing heavily impacts performance.</li></ul>|
|Reducing data to transfer and process|When updating, send only fields that have changed (delta-only loads).|
|Reducing transmission time and interruptions|For custom integrations:<ul><li>Authenticate once per load, not on each record.</li><li>Use GZIP compression and HTTP keep-alive to avoid drops during lengthy save operations.</li></ul>|
|Avoiding unnecessary overhead|For custom integrations, authenticate once per load, not on each record.|
|Avoiding computations|Use Public Read/Write security during initial load to avoid sharing calculation overhead|
|Reducing computations|<ul><li>If possible for initial loads, populate roles before populating sharing rules.<ol><li>Load users into roles.</li><li>Load record data with owners, triggering calculations in the role hierarchy.</li><li>Configure public groups and queues, and let those computations propagate.</li><li>Add sharing rules one at a time, letting computations for each rule finish before adding the next one.</li></ol></li><li>If possible, add people and data before creating and assigning groups and queues.<ol><li>Load the new users and new record data.</li><li>Optionally, load new public groups and queues.</li><li>Add sharing rules one at a time, letting computations for each rule finish before adding the next one.</li></ol></li></ul>|
|Deferring computations and speeding up load throughput|Disable Apex triggers, workflow rules, and validations during loads; investigate the use of batch Apex to process records after the load is complete.|
|Balancing efficient batch sizes against potential timeouts|When using the SOAP API, use as many batches as possible—up to 200—that still avoid network timeouts if:<ul><li>Records are large.</li><li>Save operations entail a lot of processing that cannot be deferred.</li></ul>|
|Optimizing the Lightning Platform Web Service Connector (WSC) to work with Salesforce|Use WSC instead of other Java API clients, like Axis.|
|Minimizing parent record-locking conflicts|When changing child records, group them by parent—group records by the field `ParentId` in the same batch to minimize locking conflicts.|
|Deferring sharing calculations|Use the defer sharing calculation permission to defer sharing calculations until after all data has been loaded. (See [Defer Sharing Calculation](https://developer.salesforce.com/docs/platform/salesforce-large-data-volumes-bp/guide/ldv-deployments-techniques-deferred-sharing-calculation.md).)|
|Avoiding loading data into Salesforce|Use mashups to create coupled integrations of applications. (See [Using Mashups](https://developer.salesforce.com/docs/platform/salesforce-large-data-volumes-bp/guide/ldv-deployments-techniques-using-mashups.md).)|