Best Practices

This section provides information about best practice recommendations to follow when using Tulip’s Bulk API service.

Security#

Always store and use your security token in a secure manner to protect it against unlawful access and exposure!

Performance & Thread Economy#

To expedite large data loads, the Bulk API service can support multiple threads of API invocation which is particularly relevant to initial data loads. However to start dev with a new integration with Tulip, a single threaded approach must be followed.

Tip:
To establish the optimal number of threads and corresponding optimal batch sizes for a particular project:

1. Analyze the use case and the volume of data.
   
2. Test and review the client-side integration layer.
   
3. Consult with your Tulip liaison or Tulip Support.

Per-Payload Resource Counts#

Even if the API service is developed specifically for bulk data loading, extremely large requests won’t necessarily translate to optimal performance.

For optimal performance, follow these general guidelines:

• Restrict the number data records to 500 records per batch request.
  • Start smaller in dev environments.
  • We can work with larger batch sizes in prod environments.
• For an initial database buildout, use data record types that belong to the core data record types that are the subject of the tutorial (stores, employees, catalogs, categories, products, variants, customers, orders, prices, and inventory, in this order).
  • These have direct impact on the functionality of the iOS apps in terms of almost instant availability at the front end.

If required, Tulip’s Product Support team can assist with designing and implementing data model extensions, such as custom attributes, in your payloads.

Server-Imposed Sizing Constraints#

The Bulk API service accepts payloads of up to 50 MB per request with a timeout of 60 seconds for each.

Sending Record Updates via PUT Methods#

Tulip expects full records when sending an update to Tulip’s database. Partial record updates are not supported.

Important:
Bulk load API methods require that the request payload for PUT (Updating) requests must contain ALL the attributes instead of just sending updated attributes.

In other words, if there are 10 attributes in a record that a Client normally sends to Tulip via the POST (Creation) request, it is imperative that subsequent updates to the record contain the FULL RECORDS and hence all 10 attributes even if only one was actually updated on the Client’s source system. Tulip internally always clears the record during PUT requests and replaces the contents of the existing record with the incoming UPDATE record.