Bulk update order place dates with Postman Runner

The Change Place Date endpoint moves the scheduled placement date and time on a single unsent order. When you need to move a batch of them — a site maintenance window, a holiday freeze, a fulfillment delay — Postman’s Collection Runner replays that one request once per row of a CSV you supply.

In this guide, we’ll go through setting up the collection, building the request, formatting your CSV, and reading the results. Setup takes about fifteen minutes the first time. After that, each run is a matter of swapping in a new file.

Before you begin

You’ll need four things in place.

Postman. The desktop app and the web version both work, and the steps below are identical in either. It’s free at postman.com/downloads.

An Application API key. Get one from the API keys page in RC3 for your store. Runner sends its requests from your machine rather than a customer’s browser, so it uses Application API Scope, with the key in the x-api-key header. See Authentication for how the scopes work.

The base URL for the environment you’re working in.

Order IDs aren’t portable between environments — a production order ID won’t resolve against staging, and the reverse is also true. Pull your list from the same environment you’re pointing the request at. It’s worth building a separate collection for each one so you’re never a single dropdown away from running a staging list against production.

A CSV of the orders you want to move. One row per order, containing the public order ID and, if the orders are moving to different dates, the new place date.

Setting up your collection

A collection groups your requests and holds the authorization, so you set your key once instead of repeating it on every request.

1. In Postman, select Collections in the left sidebar, then + to create a new one.
2. Name it so the environment is obvious — Acme Production or Acme Staging.
3. With the collection selected, open the Authorization tab.
4. Set Type to API Key.
5. Set Key to x-api-key and Value to your API key.
6. Set Add to to Header.

Every request you create inside this collection now inherits that key.

Building the request

1. Right-click the collection and choose Add request.

2. Set the method to PATCH.

3. Set the URL, using a Postman variable in place of the order ID:

   ProductionStaging / UAT

   https://restapi.ordergroove.com/orders/{{order_id}}/change_place_date/

4. Open the request’s Authorization tab. It should already read Inherit from parent, with the key value masked. That’s the state you want — the collection is supplying it. If the value is empty, set Type to API Key and it will populate.

5. Open the Headers tab and confirm there’s a Content-Type header set to application/json. Postman usually adds this for you once you set a JSON body, so check before you add your own. A duplicated header is a common cause of confusing failures.

6. Open the Body tab, select raw, choose JSON, and enter:

   {
     "place": "{{place}}"
   }

7. Give the request a recognizable name, like Change Place Date — Runner, and select Save.

Building your CSV file

Runner loops over this file and fires one request per row. What the file needs depends on whether your orders are moving to different dates or all to the same one.

Moving orders to different dates

Use two columns. The headers have to match the Postman variable names exactly: order_id and place.

Place dates use the format YYYY-MM-DD HH:MM:SS. Convention is to set the time to 00:00:00 so the order is queued at the start of the day.

order_id,place
8a996277296541208ee2f2e42e9482fa,2027-09-15 00:00:00
f7be9c867f164e81adb824c04d9c3537,2027-09-16 00:00:00

Moving all orders to the same date

Use one column, order_id. Leave the dates out of the file entirely — the date goes in the request body instead, as a fixed value.

order_id
8a996277296541208ee2f2e42e9482fa
f7be9c867f164e81adb824c04d9c3537

You’ll also need to change the request body to hardcode the date. See Updating all orders to the same date for that step.

Either way, save the file as a plain .csv. In Excel, that’s File > Save As, then choosing CSV.

Running the update

1. Right-click the collection and choose Run.
2. Confirm that only the Change Place Date request is checked. If the collection holds other requests, uncheck them.
3. Under Iteration Data, select Datafiles, then + Select from computer, and choose your CSV. Postman shows a preview of the parsed rows — check that order_id and place line up in the right columns.
4. Check the Iterations count. It should match the number of orders in your file. If it doesn’t, something’s off in the CSV, usually a trailing blank row or a stray column.
5. Select Start Run. Runner fires one request per row and shows a live pass/fail list as it goes.

Reviewing your results

Select any row in the results list to see the full request and response for that order, including the place value that came back. Use the status code to triage:

If you see a code that isn’t listed here, capture the row’s full response and check with your Ordergroove contact rather than re-running it blindly.

Before you close Runner, select Export Results to save a JSON log of every request and response. Keep it alongside the CSV you ran — together, the pair is your record of exactly what changed and when.

Updating all orders to the same date

If every order in your list is moving to the same date, you can drop the place variable and hardcode the value instead.

1. In the request body, replace the variable with the date itself:

   {
     "place": "2027-09-15 00:00:00"
   }

2. Save the request.

3. Use a single-column CSV containing only order_id, as shown in Moving all orders to the same date.

4. Run it exactly as above.

Everything else is the same. Runner is now pulling one variable from the file instead of two.

Related resources

If you have any questions about the endpoint, or a run that keeps failing, reach out to your Ordergroove contact. We’ll be happy to walk through it with you.