Skip to main content
Keep existing StoreRocket locations aligned with the information your system owns. This guide includes complete JavaScript and PHP scripts: they read every page, check the target IDs, preview changes and apply them with PATCH.

Before you start

Follow the quickstart to set STOREROCKET_TOKEN and STOREROCKET_PROJECT_ID. Your token needs location:read and location:update, and the project needs API access. JavaScript uses Node.js 22 or later. PHP uses PHP 8.2 or later with cURL. Run these examples on your server or from your terminal. Keep a mapping between each ID in your own system and the public StoreRocket location id. Read existing IDs from List locations; when you create a location, save its returned data.id. Names and addresses can change or be shared by multiple locations, so use IDs for matching.

Prepare your changes

Save a file named changes.json beside the script. Replace LOCATION_ID with an existing public location ID in this project. Include one object per location, containing only the fields you intend to change:
changes.json
This updates the phone and Monday’s hours. Omitted fields and other weekdays stay unchanged. The script removes id from the request body and uses it in the URL. Use writable field names, rather than sending a read response back as an update. For example, read responses contain fields arrays, but writes accept named objects. Send only fields your source system controls, so a sync preserves unrelated dashboard edits.
An omitted hours value or "hours": {} preserves the schedule. "hours": null removes it, and "hours": {"mon": null} clears only Monday. PHP must preserve an empty JSON object as an object; the script below does this when reading your file. See the opening-hours contract.

Read every page

Location lists are paginated. Each response has a data array and pagination links and meta; a request reads at most 100 locations. Both scripts keep limit=100 and includeHours=1 on each request and continue through meta.last_page. They check every target ID before sending the first PATCH. If any target is missing from the chosen project, the script stops without sending an update. Pagination reads the current data on each page; it is not a frozen snapshot. Run one sync per project at a time and avoid changing the location list while collecting IDs.

Copy the complete script

Choose your language. Save the JavaScript example as sync-locations.mjs or the PHP example as sync-locations.php, in the same folder as changes.json. No SDK or additional library is required.

Preview first

Run one of these commands from the folder containing the script and changes.json:
The script reads your locations and prints Would PATCH with the ID and proposed fields. It sends no write requests in preview mode. Check the project, IDs, fields and any explicit clearing before applying.

Apply the reviewed changes

Each successful PATCH returns 200; the script prints Updated with the location ID. Requests run sequentially. The examples update existing locations only and do not create or delete locations.

Handle errors and retries

A PATCH is atomic for one location, not for the whole file. If a later request fails, earlier successful updates remain saved. The script prints each completed ID so you can resume deliberately. A location can also change after the preflight read; a later 404 stops the script. The API uses a shared limit of 1,000 requests per minute. The scripts retry only 429 responses and show errors rather than reporting a failed request as successful. See the error reference for the complete policy, including why a failed connection after POST can lead to a duplicate if retried blindly. For opening hours, text fields, filters and attachments, follow the PATCH field contract. Add creation or deletion to an integration as explicit operations with their own handling.