> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://developer.ordergroove.com/lifecycle/order/bulk-place-dates/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.ordergroove.com/_mcp/server. # Bulk update order place dates with Postman Runner The [Change Place Date](/reference/rest-rpc-api/orders/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. > **Note** > > This guide covers order place dates. To change when a subscriber receives their upcoming order reminder, use [Change Email Reminder](/reference/rest-rpc-api/subscriptions/change-email-reminder) on the subscription instead. --- ## 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](https://www.postman.com/downloads/). **An Application API key.** Get one from the [API keys page in RC3](https://rc3.ordergroove.com/keys/) 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](/api-reference/authentication) for how the scopes work. > **Warning** > > Treat your API key like a password. Don't paste it into Slack, a ticket, an email, or a shared document. **The base URL for the environment you're working in.** | Environment | Base URL | | ------------- | ----------------------------------------- | | Production | `https://restapi.ordergroove.com` | | Staging / UAT | `https://staging.restapi.ordergroove.com` | 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: **`Production`** ```text title="Production" https://restapi.ordergroove.com/orders/{{order_id}}/change_place_date/ ``` **`Staging / UAT`** ```text title="Staging / UAT" https://staging.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: ```json { "place": "{{place}}" } ``` 7. Give the request a recognizable name, like `Change Place Date — Runner`, and select **Save**. > **Warning** > > Runner uses the last saved version of a request, not what's currently on screen. Any time you change the URL, headers, or body, save before you run. --- ## 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. **`orders.csv`** ```csv title="orders.csv" 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. **`orders.csv`** ```csv title="orders.csv" 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](#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**. > **Info** > > Start with a two-row file. Run it, confirm the dates landed where you expected, then run your full list. --- ## 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. > **Note** > > Runner sends requests back to back, which can trip our rate limits on larger files. The threshold is 6,000 requests per IP per minute, and requests that return `429` are safe to retry — see [API Rate Limits](/api-reference/rate-limits). If you start seeing `429` responses, set a **Delay** between iterations in Runner's settings, or split the file into smaller batches. For runs in the thousands of rows, give your Ordergroove contact a heads-up before you start. --- ## 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: | Code | Meaning | What to check | | ----- | ------------------------------ | ----------------------------------------------------------------------- | | `200` | Success — the date was updated | Nothing | | `400` | Bad request | Timestamp format. It must be `YYYY-MM-DD HH:MM:SS` | | `403` | Request not authorized | The key value on the collection, and that the header key is `x-api-key` | | `404` | Order not found | That the order ID exists in the environment you're pointing at | | `429` | Rate limit exceeded | Add a delay between iterations, or split the file | 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: ```json { "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](#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 #### [Change Place Date](/reference/rest-rpc-api/orders/change-place-date) The endpoint reference, including the full response body. #### [Change Email Reminder](/reference/rest-rpc-api/subscriptions/change-email-reminder) Change when a subscriber receives their upcoming order reminder. #### [Authentication](/api-reference/authentication) Generating and using API keys, and how the scopes work. #### [API Rate Limits](/api-reference/rate-limits) Current thresholds and how throttling behaves. #### [Collection Runner](https://learning.postman.com/docs/tests-and-scripts/running-collections/test-data/working-with-data-files/) Postman's own documentation on data files and iterations. 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. > APIs, SDKs, and guides for building subscription commerce with Ordergroove.