When collecting data on a large number of products, a batch request can help streamline the process into a more convenient workflow. Instead of launching a separate request for each product, a batch request allows you to include up to 1,000 URLs in a single request, and have the results delivered to your cloud storage solution.
In the following examples, we'll demonstrate real-world use cases, and show how to use batch requests to most efficiently achieve the intended goal.
Example one - collecting data for multiple products
In this first example, we'll collect data for multiple unique products. To do so, we set the URLs of the products we want to collect in the url fields of the requests object.
Nimble APIs requires that a base64 encoded credential string be sent with every request to authenticate your account. For detailed examples, see Web API Authentication.
Parameters that are placed outside the requests object, such as vendor, storage_type, storage_url, and callback_url , are automatically applied as defaults to all defined requests.
If a parameter is set both inside and outside the requests object, the value inside the request overrides the one outside.
Example two - collecting products from multiple vendors
In the next example, we'll collect products from multiple vendors. To do so, we'll take advantage of the requests object, which allows us to set any parameter inside each request:
In the above example, we've set Walmart as our desired vendor for the first two requests. On the third request, we haven't set a vendor implicitly, and so the default vendor defined outside the requests object is used instead, which in this case is Amazon.
Example three - collecting the same product from multiple countries
Any parameter can be defined inside and/or outside the requests object. We can take advantage of this in some cases by setting our URL once as a default and setting various other parameters in the requests object. For example:
In the above example, three total requests would be made for the same Walmart product - each time from a different country and locale.
Request Options
Batch requests use the same parameters as asynchronous requests, with the exception of the requests object.
Parameter
Required
Description
requests
Optional
Allows for defining custom parameters for each request within the bulk. Any of the parameters below can be used in an individual request.
vendor
Required
String walmart, amazon
url
Required
The product or search pages to collect.
country
Optional (default = all)
state
Optional
String | For targeting US states (does not include regions or territories in other countries). Two-letter state code, e.g. NY, IL, etc.
city
Optional
zip
optional
String A 5-digit US zip code. If provided, the closest store to the provided zip code is selected.
locale
Optional (default = en)
String | LCID standard locale used for the URL request. Alternatively, user can use auto for automatic locale based on country targeting.
parse
Optional (default = false)
Enum: true | false Instructs Nimble whether to structure the results into a JSON format or return the raw HTML.
storage_type
Optional
ENUM: s3 | gs Use s3 for Amazon S3 and gs for Google Cloud Platform.
Leave blank to enable Push/Pull delivery.
storage_url
Optional
Repository URL: s3://Your.Bucket.Name/your/object/name/prefix/
Leave blank to enable Push/Pull delivery.
callback_url
Optional
A url to callback once the data is delivered. The E-commerce API will send a POST request to the
callback_url with the task details once the task is complete (this “notification” will not include the requested data).
storage_compress
Optional (default = false)
When set to true, the response saved to the storage_url will be compressed using GZIP format. This can help reduce storage size and improve data transfer efficiency. If not set or set to false, the response will be saved in its original uncompressed format.
Setting GCS/AWS access permissions
GCS Repository Configuration
In order to use Google Cloud Storage as your destination repository, please add Nimble’s system user as a principal to the relevant bucket. To do so, navigate to the “bucket details” page in your GCP console, and click on “Permission” in the submenu.
Next, past our system user [email protected] into the “New Principals” box, select Storage Object Creator as the role, and click save.
That’s all! At this point, Nimble will be able to upload files to your chosen GCS bucket.
S3 repository configuration
In order to use S3 as your destination repository, please give Nimble’s service user permission to upload files to the relevant S3 bucket. Paste the following JSON into the “Bucket Policy” (found under “Permissions”) in the AWS console.
Follow these steps:
1. Go to the “Permissions” tab on the bucket’s dashboard:
2. Scroll down to “Bucket policy” and press edit:
3. Paste the following bucket policy configuration into your bucket:
Important: Remember to replace “YOUR_BUCKET_NAME” with your actual bucket name.
Here is what the bucket policy should look like:
4. Scroll down and press “Save changes”
S3 Encrypted Buckets
If your S3 bucket is encrypted using an AWS Key Management Service (KMS) key, additional permissions to those outlined above are also needed. Specifically, Nimble's service user will need to be given permission to encrypt and decrypt objects using a KMS key. To do this, follow the steps below:
Sign in to the AWS Management Console and open the AWS Key Management Service (KMS) console.
In the navigation pane, choose "Customer managed keys".
Select the KMS key you want to modify.
Choose the "Key policy" tab, then "Switch to policy view".
Click "Edit".
Add the following statement to the existing policy JSON, ensuring it's inside the Statement array:
That's it! You've now given Nimble APIs permission to encrypt and decrypt objects, enabling access to encrypted buckets.
Please add Nimble's system/service user to your GCS or S3 bucket to ensure that data can be delivered successfully.
Response
Initial Response
Batch requests operate asynchronously, and treat each request as a separate task. The result of each task is stored in a file, and a notification is sent to the provided callback any time an individual task is completed.
