Orders/Search not receiving location_ids

I am using Google’s Apps Script to design a small internal app to track customer activity.

Part of what I’m needing to do is track customer orders with specific line items in a given time frame. In the API Explorer, I am able to do this easily with the given curl

curl https://connect.squareup.com/v2/orders/search \
  -X POST \
  -H 'Square-Version: 2023-08-16' \
  -H 'Authorization: Bearer XXXXX' \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "filter": {
        "date_time_filter": {
          "closed_at": {
            "end_at": "2023-09-20",
            "start_at": "2023-08-01"
        "state_filter": {
          "states": [
      "sort": {
        "sort_field": "CLOSED_AT",
        "sort_order": "DESC"
    "location_ids": [

I set up my headers in Apps Script as follows:

{ method: 'post',
   { 'Square-Version': '2022-08-23',
     Authorization: 'Bearer XXXXX',
     Accept: 'application/json' },
  muteHttpExceptions: true,
  payload: '{"query":{"filter":{"date_time_filter":{"closed_at":{"end_at":"2023-09-20T16:39:31.415Z","start_at":1692463171416}},"state_filter":{"states":["COMPLETED"]}},"sort":{"sort_field":"CLOSED_AT","sort_order":"DESC"}},"location_ids":["XXXXX"]}' }

Using that request and payload, I get the following error:

Response content: {“errors”: [{“code”: “BAD_REQUEST”,“detail”: “Must provide at least 1 location_id.”,“field”: “location_ids”,“category”: “INVALID_REQUEST_ERROR”}]}

I have tried re-ordering the arguments in the payload, removing all arguments except “location_ids”, and everything I can think of to confirm spelling, capitalization, etc. without any success.
Is there another way to search orders or something I am missing in how I have structured my request?

As an additional note, I have confirmed that other API endpoints can be hit and respond correctly. So far, orders/search is the only one that doesn’t appear to work.

Is there any white space in the location_id your passing in? :slightly_smiling_face:

No white space. It is 13 characters copied directly from the values I used to test in the Production API Explorer.

Are you able to put in a break point an print the value to confirm that it’s not somehow being malformed? :slightly_smiling_face:

What I pasted above with my token and location id redacted is what the Apps Script debug says is being sent. I’ve confirmed that other end points work as expected with similar payloads.

{ method: ‘post’,
{ ‘Square-Version’: ‘2022-08-23’,
Authorization: ‘Bearer XXXXX’,
Accept: ‘application/json’ },
muteHttpExceptions: true,
payload: ‘{“query”:{“filter”:{“date_time_filter”:{“closed_at”:{“end_at”:“2023-09-20T16:39:31.415Z”,“start_at”:1692463171416}},“state_filter”:{“states”:[“COMPLETED”]}},“sort”:{“sort_field”:“CLOSED_AT”,“sort_order”:“DESC”}},“location_ids”:[“XXXXX”]}’ }

Is there any way to get a list of the orders that have been processed without using the orders/search endpoint? I am still unable to successfully hit the endpoint with my location_id through Apps Script

What’s your location_id? Currently SearchOrders is the only why to list orders if you don’t already have the order_id. :slightly_smiling_face:

The location_id for our only location is L4XFA8EB8MYVZ

From what I can see in the API Logs is your calling sandbox with your production location_id. You’ll need to change the location_id to the sandbox location_id or switch to production to see the orders from the production location.

Also in production I see that your making blank requests to SearchOrders. You’ll need to provide your request body to the endpoint for successful API calls. :slightly_smiling_face:

I’m sure that, in my attempts to get any other response, some of my attempts were to the sandbox URL.

Currently, I have it set up to do a POST request to https://connect.squareup.com/v2/orders/search
That request is using my production bearer token and our location id.

I have also attempted hitting https://connect.squareupsandbox.com/v2/orders/search using the sandbox token and location id.

In all cases, the error returned is the following:
Response content: {“errors”: [{“code”: “BAD_REQUEST”,“detail”: “Must provide at least 1 location_id.”,“field”: “location_ids”,“category”: “INVALID_REQUEST_ERROR”}]}

According to the Logs there isn’t a request body being passed in when your calling production which is why your getting the location error. If you try the following with your credentials does it pull in the order data? This is what I used for my Script.

function callSquareSearchOrders() {
  // Replace with your Square API access token and location ID
  var accessToken = 'YOUR_ACCESS_TOKEN';
  var locationId = 'YOUR_LOCATION_ID';

  // Square SearchOrders API endpoint
  var apiUrl = 'https://connect.squareup.com/v2/orders/search';

  // Define your search criteria here
  var searchCriteria = {
    location_ids: [locationId],
    query: {
      date_time_filter: {
        created_at: {
          start_at: '2023-09-01T00:00:00Z', // Replace with your start date
          end_at: '2023-09-30T23:59:59Z'   // Replace with your end date

  // Convert the search criteria to a JSON string
  var payload = JSON.stringify(searchCriteria);

  // Define the headers for the request
  var headers = {
    'Authorization': 'Bearer ' + accessToken,
    'Content-Type': 'application/json'

  // Make the API request
  var options = {
    'method': 'post',
    'headers': headers,
    'payload': payload

  var response = UrlFetchApp.fetch(apiUrl, options);

  // Check if the request was successful (HTTP status code 200)
  if (response.getResponseCode() === 200) {
    var responseData = JSON.parse(response.getContentText());
  } else {
    Logger.log('Error: ' + response.getResponseCode() + ' - ' + response.getContentText());


Thanks Bryan!

I was able to get a successful response using that code.
I should be able to move forward from there.
Thank you for all of your help!

It appears the issue was because my headers were using

Accept: "application/json"

instead of

'Content-Type': "application/json"

I wanted to let you know, in the event this comes up for other users in the future.