Developer Tools

GraphQL Overview Beta release

This is pre-release documentation for an API in public beta and is subject to change.

GraphQL streamlines your application flow by letting you request exactly the data you need. GraphQL can reduce development time and improve the customer experience by making requests more efficient. With fewer, faster, and more compact data transfers, GraphQL can be especially beneficial for resource-constrained mobile applications and in modern frontend development.

The open-source GraphQL standard defines both a query language and a runtime that retrieves data using queries. A single GraphQL query can retrieve data that would require multiple Square API calls.

Square GraphQL features include:

A standards compliant GraphQL endpoint that serves multiple Square graphs. You can send one query to retrieve exactly the data you need from multiple Square objects and graphs.
Support for OAuth access management.
Support for testing in the Square Sandbox environment.
Statically typed schemas that enable developer tooling. You can view the schema documentation when you sign in to GraphQL Explorer.

Square GraphQL supports query operations only; it doesn't support mutations or subscriptions. Applications that want to use GraphQL for faster querying and need to perform write operations must use both GraphQL and Square APIs or Square SDKs.

Link to section
Supported Square graphs

Square GraphQL supports query operations for the following Square graphs:

Cards
Catalog
Customers
Inventory
Merchants
Orders
Payments
Refunds

A graph provides similar read access to data as the corresponding Square API, as well as access to data that crosses API boundaries. For example, an Orders query can return the email address, phone number, and other attributes of the customer associated with the order.

Link to section
How to access Square GraphQL

Square provides two endpoints where you can send GraphQL queries:

For queries in the production environment, call:

https://connect.squareup.com/public/graphql

For queries in the Sandbox test environment, call:

https://connect.squareupsandbox.com/public/graphql

Unlike Square API requests, a GraphQL query specifies the exact data to return, including data that crosses API boundaries. To get started making GraphQL queries against Square data, try GraphQL Explorer. You can choose from several sample queries or write your own queries. For more information, see GraphQL basics or GraphQL Explorer Overview.

To get the required merchant ID for your Square GraphQL queries, query currentMerchant for the id field. (See an example.)

The Square GraphQL endpoint also works with third-party GraphQL tools, such as GraphiQL.

For example, this example cURL query retrieves an order and the customer who made the order:

curl https://connect.squareupsandbox.com/public/graphql \
  -X POST \
  -H 'Authorization: Bearer <ACCESS_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{ 
    "query": "{ orders( filter: { id: { equalToAnyOf: [\"<ORDER_ID>\"]} merchantId: { equalToAnyOf: [\"<MERCHANT_ID>\"]}}) { nodes { state updatedAt customer { id emailAddress }}}}"
  }'

The data object in the response contains the query results. If any errors are encountered while processing the query, Square returns an errors list. A response can contain both data with (partial) query results and errors.

Link to section
Get support for Square GraphQL

Tag your feedback, issues, and questions with graphql-api and post them on the Square Developer forums or email [email protected].

Link to section
GraphQL basics

You should understand the following concepts when working with Square GraphQL queries:

Objects - An object is a collection of fields. The data type of a field can be a scalar, complex type, or enum, as a single value or an array. For example, the Customer.phoneNumber field is a String type and the Customer.address field is an Address type.
Enums - An enum defines the set of valid values for fields of the given enum type. For example, the Currency enum defines all possible values for the Money.currency field.
Interfaces - An interface defines fields that must be included in any object that implements the interface. For example, CatalogItem and CatalogCategory implement the CatalogObject interface, so both objects include all CatalogObject fields. The Catalog sample query in GraphQL Explorer shows how you can use inline fragments to request fields based on different implementations.
Non-Null - An exclamation mark (!) appended to the data type of a field indicates that the value of the field must be non-null when returned or when provided as an argument.
Schema - A schema defines the data model (graph). It describes the objects and fields that are available to query, as well as the entry points, hierarchical relationships, arguments, and type information that determine valid query syntax. You can view the Square GraphQL schema in the Documentation Explorer pane in GraphQL Explorer.

For more information about GraphQL basics, see Introduction to GraphQL at graphql.org.

Link to section
Queries

A query is an operation that retrieves specific data. Every query contains at least one graph entry point (such as orders, catalog, or customers) and specifies the fields to return. Because queries are also objects, you can name and reuse queries.

A query is enclosed in curly braces ({ }). Lines that begin with a # character are treated as comments and ignored. For example, a simple query might use the following format:

# This is a simple query format
{
  field(arg: "value") {
    subfield
  }
}

The following example query from GraphQL Explorer requests the status and mainLocation fields for a given merchant:

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  merchants( filter: { id: { equalToAnyOf: ["<MERCHANT_ID>"]}}) {
    nodes {
      status
      mainLocation {
        id
        name
        createdAt
        capabilities
      }
    }
  }
}

Because mainLocation is a complex type, you must also specify the Location subfields that you want to retrieve. If successful, the query returns results similar to the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "data": {
    "merchants": {
      "nodes": [
        {
          "status": "ACTIVE",
          "mainLocation": {
            "id": "M8AKAD8160ABC",
            "name": "Default Test Account",
            "createdAt": "2022-07-10T16:53:39.885Z",
            "capabilities": [
              "CREDIT_CARD_PROCESSING",
              "AUTOMATIC_TRANSFERS"
            ]
          }
        }
      ]
    }
  }
}

You can optionally specify the query operation type and operation name in your queries. Naming a query can help with reuse, debugging, and logging.

Link to section
Filters

You can filter a query to conditionally retrieve data based on specified criteria. Many Square GraphQL filters are equivalent to filters used for list and search endpoints in Square APIs.

All graph entry points (except currentMerchant) accept a filter argument and define valid filtering criteria in a top-level input type. For example, the following cardsOnFile query uses fields from the CardOnFileFilter input type to retrieve the cards on file for a customer that are enabled for payments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

query GetCardsOnFile {
  cardsOnFile(
    filter: {
      customerId: {
        equalToAnyOf: ["<CUSTOMER_ID>"]
      }
      includeDisabled: {
        equalTo: false
      }
      merchantId: {
        equalToAnyOf: ["<MERCHANT_ID>"]
      }
    }
  ) {
    nodes {
      id
      cardBrand
      last4
      expMonth
      expYear
    }
  }
}

Most graph entry points allow you to specify an id filter that lets you retrieve a specific object. The following example query uses the id filter to retrieve a specific payment:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

query GetPayment {
  payments(
    filter: {
      id: { 
        equalToAnyOf: ["<PAYMENT_ID>"]
      }
      merchantId: {
        equalToAnyOf: ["<MERCHANT_ID>"] 
      }
    }
  ) {
    edges {
      node {
        status
        createdAt
        updatedAt
        amountMoney {
          amount
          currency
        }
      }
    }
  }
}

Link to section
Required merchant ID filter

All graph entry points (except currentMerchant) require a merchant ID filter. You can use currentMerchant to get the merchant ID and other merchant-related fields, as shown in the following example query:

{
  currentMerchant {
    id
    status
    mainLocation {
      id
    }
  }
}

Link to section
Variables

You can use variables to replace static or dynamic values in query arguments. For example, by using a variable for the merchant ID that's required to access Square data, you can easily reuse the query for different merchants.

The format for a variable is $variableName (a dollar sign followed by the variable name). To use a variable in a query, you must:

Declare that the variable is used in the query.
Replace the value in the query with the variable.
Define the value of the variable.

The following example cURL query uses two variables, $merchantId and $searchText:

curl https://connect.squareupsandbox.com/public/graphql \
-X POST \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
  "query": "query CatalogTextSearch($merchantId: ID!, $searchText: [String!]!) { catalog(filter: { merchantId: { equalToAnyOf: [$merchantId]}, text: { value: $searchText}}) { nodes { id ... on CatalogItem { name }}}}",
  "variables": { "merchantId": "8QJT7EXAMPLE", "searchText": ["gluten", "free"]}
}'

Note how the variables are used in the example query:

The variables and their types are declared as arguments for the query operation:

query CatalogTextSearch($merchantId: ID!, $searchText: [String!]!)

The $merchantId variable is used by the merchantId filter in the query:

merchantId: { equalToAnyOf: [$merchantId]}

The $searchText variable is used by the text filter in the query:

text: { value: $searchText}

The values for both variables are defined in the variables object:

"variables": { "merchantId": "8QJT7EXAMPLE", "searchText": ["gluten", "free"]}

Values are passed in a separate, transport-specific (usually JSON) variables dictionary. You can also use a separate JSON file to pass in variable values.

Link to section
Using query variables in GraphQL Explorer

In GraphQL Explorer, you can declare and reference variables in query arguments using the $variableName format, similar to the preceding example. To define the values of variables, use the Query Variables pane.

The sample queries available in GraphQL Explorer show how to use variables in queries and pass in their values.

Link to section
Pagination

Pagination is used to retrieve all the results of a query using paged responses. Square GraphQL uses the cursor method of pagination. You retrieve pages of data by optionally specifying the page size and then use a pointer (cursor) to keep track of where the next page of data should be retrieved from.

The following example query uses pagination to retrieve all orders for a given merchant and location:

The first field specifies the page size, which is the maximum number of items to return in each response page. If you omit this field, the default page size is used.
The pageInfo field requests the hasNextPage and endCursor to use for forward pagination.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

query PaginatedQuery {
  orders(
    filter: { merchantId: { equalToAnyOf: ["<MERCHANT_ID>"]}, location: { equalToAnyOf: ["<LOCATION_ID>"]}}
    first: 3
  ) {
    nodes {
      id
      customer {
        givenName
        familyName
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

The following is an example paged response:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "data": {
    "orders": {
      "nodes": [
        {
          "id": "kfn0S4F0rC765YIotVsguEA8taB",
          "customer": {
            "givenName": "Arjun",
            "familyName": "Mahanti"
          }
        },
        {
          "id": "O2ajrDfbyhPtAUAR64zzKNSouaB",
          "customer": {
            "givenName": "Jennifer",
            "familyName": "Shen"
          }
        },
        {
          "id": "a2VSRiNIsFXJ0rUvTfrBYkTkvaB",
          "customer": null
        }
      ],
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": "i7QRXHX2HKYqHrk...G4yFQ"
      }
    }
  }
}

If more pages of data are available, hasNextPage is true and endCursor contains the cursor.

In your next query, include the after field and provide the cursor from the previous response, as shown in the following example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

query PaginatedQuery {
  orders(
    filter: { merchantId: { equalToAnyOf: ["<MERCHANT_ID>"]}, location: { equalToAnyOf: ["<LOCATION_ID>"]}}
    first: 3
    after: "i7QRXHX2HKYqHrk...G4yFQ"
  ) {
    nodes {
      id
      customer {
        givenName
        familyName
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Continue using the cursor from each response page in a subsequent query until you retrieve all response pages.

In the last response page, hasNextPage is false and endCursor is null, as shown in the following example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "data": {
    "orders": {
      "nodes": [
        {
          "id": "Yja9D6QK6NVI8br85QWFoaTDvaB",
          "customer": {
            "givenName": "Mio",
            "familyName": "Yoshigiwa"
          }
        },
        {
          "id": "YlvzJWQgEcmvT2zcEZHJMB3SuaB",
          "customer": {
            "givenName": "Elisa",
            "familyName": "Rizzo"
          }
        }
      ],
      "pageInfo": {
        "hasNextPage": false,
        "endCursor": null
      }
    }
  }
}

The pagination process might vary depending on the Square graph being queried. For example, payments and refunds can also be paginated in a backward direction using the last and before fields and the startCursor cursor.

In addition, valid first and last page size values might vary depending on the graph or the complexity score of the query.

Link to section
Authentication process

GraphQL queries must provide a bearer access token in the Authorization header, just like Square API requests. The access token determines the data that you have permissions to view.

A personal access token grants full access to the data in your Square account. If you query using a personal access token, make sure to use one that's valid for the target Sandbox or production environment.
An OAuth access token grants granular access based on a set of permissions. If you query using an OAuth access token, the results are scoped to the permissions you requested and were granted. For example, if an orders query includes fields for the customer associated with the order, you need both ORDERS_READ and CUSTOMERS_READ to get full results. For more information about the OAuth flow, see OAuth API Overview.
Fields that you're not permitted to view are set to null in the results. In addition, the response contains an errors list with one or more SCOPE_MISSING errors. The error message provides related information, such as the missing OAuth scope.

{% accordion expanded=false %} {% slot "heading" %}

Link to section
Setting the access token in GraphQL Explorer

{% /slot %}

If you're using GraphQL Explorer, the access token for the query is provided in the Request Headers pane. When signed in with your Square account, you can use the Add access token button to select a personal access token that grants full access to all data in your Square account. To test a specific set of permissions, you can paste an OAuth access token into the Request Headers pane. {% /accordion %}

Link to section
Rate limiting for Square GraphQL

Rate limits are intended to enforce reasonable API usage. Square uses a calculated query cost method for rate limiting based on the following limits:

Applications can send a maximum of 10 queries per second (10 QPS).
A query can have a maximum depth of 10. Query depth is the number of nested levels of the query fields.
A query can have a maximum complexity score of 250 points.
The 250 maximum complexity score combined with the 10 QPS limit results in an implicit limit of 2500 complexity points consumed per second.
Queries that exceed the maximum complexity score return a COMPLEXITY_MAX_REACHED error.

Link to section
Return the complexity score for a query

For testing or debugging purposes, you can direct Square to return the complexity score for a query. To do so, include the x-graphql-include-debug request header and set the value to 1. In GraphQL Explorer, add the header to the Request Headers pane.

{
  "Authorization": "Bearer <ACCESS_TOKEN>",
  "x-graphql-include-debug": 1
}

Square returns the complexity score in the extensions object, as shown in the following excerpt:

{
  "data": {
    ...
  },
  "extensions": {
    "requestId": "NWPefYffJdBEA",
    "complexityScore": 24
  }
}

{% accordion expanded=false %} {% slot "heading" %}

Link to section
How to estimate the query cost

{% /slot %}

You can calculate the cost of a query using the following point scale.

Two points for each graph entry point, connection object, and join relationship - A query contains at least one graph entry point and one connection object

A one-to-many relationship that enables access to items as a paginated list.

, so the minimum query cost is four points. For the following example query, add two points for the orders entry point, two points for the nodes connection object, and two points for the refunds join relationship.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
```
{
  orders(<args>) {            # entry point to the Orders graph
    nodes {                   # connection object
      refunds {               # join relationship
        reason
      }
      location {              # object
        id
      }
    }
  }
}
```
The location object is counted next.
One point for each object, union, or interface - In a query, every specified field whose data type is an object, union, or interface costs one point. For the previous example query, add one point for the location object, which brings the total complexity score of the query to seven points.
Note that when a query includes a first or last page size argument, the specified value also counts as points.
Zero points for scalars and enums - Scalars and enums don't incur a cost because they return a final value in query results. In the example query, reason is a String scalar value and id is an ID scalar value. {% /accordion %}

{% accordion expanded=false %} {% slot "heading" %}

Link to section
Complexity score and page size

{% /slot %}

In a query, the first and last arguments can be used to specify the page size, which is the maximum number of results to include in a single page of the response. For queries that include a first or last argument, the specified page size value counts as points. For example, first: 20 adds 20 points to the complexity score.

The complexity score might also determine the maximum possible page size for a query. As the complexity score increases, the maximum possible page size decreases. For example, the most simple orders query costs four connection points, which effectively limits the maximum page size to 246. Adding location to the query reduces the limit to 245.

Some graphs enforce a lower maximum page size limit. For example, a customers query has a maximum page size of 20. In this case, the complexity score is less likely to result in rate limiting based on the query complexity. {% /accordion %}

Link to section
Limitations

You should be aware of the following limitations when working with Square GraphQL.

Square GraphQL supports query operations only; it doesn't support mutation or subscription operations. Applications that need to perform both read and write operations should use Square APIs or Square SDKs.
Rate and query cost limits are applied to Square GraphQL queries.
Square SDKs cannot be used to send GraphQL queries.
The API Logs feature in the Developer Dashboard does not include GraphQL queries.
Not all Square APIs have corresponding GraphQL support. For the list of supported graphs, see Supported Square graphs.
Square graphs generally provide access to the same data as the corresponding Square APIs, as well as expanded, direct access to referenced objects that cross API boundaries. However, graphs are not always at parity with corresponding Square APIs. For example:
- Compared to the corresponding list or search endpoints, GraphQL provides more filters for payments but fewer filters for customers.
- You cannot retrieve custom attributes for merchants, orders, or customers using GraphQL queries. Only catalog custom attributes are supported.
Although Square graphs are continually updated to reflect the latest version of the corresponding Square APIs, there might be exceptions. You should use the current schema as the source of truth for GraphQL support. You can view the schema in GraphQL Explorer or by using the introspection system, as shown in this simple introspection query:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
```
{
  __schema {
    types {
      name
      description
      kind
    }
  }
}
```
For more information, see Introspection at graphql.org.

Link to section
Migration notes

The Square GraphQL schema generally reflects the latest version of the corresponding Square APIs. The following are backward-incompatible changes to the schema that might require updates to your application code.

Link to section
Catalog graph: Image field changes

Effective date: 2023-05-23

The following CatalogItem field is changed:

Previous name and type	New name and type
`image: CatalogImage`	`images: [CatalogImage]`

Link to section
Orders graph: OrderFilter fields renamed

Effective date: 2023-04-12

The following OrderFilter fields are renamed:

Previous name	New name
`customers`	`customer`
`ids`	`id`
`locations`	`location`
`merchants`	`merchantId`
`sourceNames`	`sourceName`
`states`	`state`

Link to section
Merchants graph: Merchant ID is passed as a filter

Effective date: 2023-04-12

The required merchant ID is now passed using the id filter.

Example: Previous argument

1
2
3
4
5
6
7
8
9
10
11

query MerchantsQuery {
  merchants(
    filter: {
      merchants: [ "<MERCHANT_ID>" ]
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Example: Current argument

1
2
3
4
5
6
7
8
9
10
11
12
13

query MerchantsQuery {
  merchants(
    filter: {
      id: { 
        equalToAnyOf: [ "<MERCHANT_ID>" ]
      }
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Link to section
Customers graph: CustomerFilter field renamed

Effective date: 2023-04-12

The following CustomerFilter field is renamed:

Previous name	New name
`ids`	`id`

Link to section
Catalog graph: Separate entry point for catalog items and merchant ID is passed as a filter

Effective date: 2023-04-01

The Catalog graph now provides separate entry points for querying catalog objects and catalog items. As part of this change, the all and items top-level fields are removed. In addition, the merchant ID is now passed as a filter.

Example: Previous catalog objects query

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

query CatalogObjectsQuery {
  catalog(
    merchantId: { 
      equalToAnyOf: [ "<MERCHANT_ID>" ]
    }
    all {     
      filter: {
        id: { 
          equalToAnyOf: [ "<CATALOG_OBJECT_ID>" ]
        }
      }
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Example: Current catalog objects query

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

query CatalogObjectsQuery {
  catalog(
    filter: {
      merchantId: { 
        equalToAnyOf: [ "<MERCHANT_ID>" ]
      }
      id: { 
        equalToAnyOf: [ "<CATALOG_OBJECT_ID>" ]
      }
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Example: Previous catalog items query (uses the catalog entry point)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

query CatalogItemsQuery {
  catalog(
    merchantId: { 
      equalToAnyOf: [ "<MERCHANT_ID>" ]
    }
    items {     
      filter: {
        id: { 
          equalToAnyOf: [ "<CATALOG_ITEM_ID>" ]
        }
      }
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Example: Current catalog items query (uses the catalogItems entry point)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

query CatalogItemsQuery {
  catalogItems(
    filter: {
      merchantId: { 
        equalToAnyOf: [ "<MERCHANT_ID>" ]
      }
      id: { 
        equalToAnyOf: [ "<CATALOG_ITEM_ID>" ]
      }
    }
  ) {
    nodes {
      # requested fields
    }
  }
}

Link to section
Catalog graph: CatalogFilter fields renamed

Effective date: 2023-03-28

The following CatalogFilter fields are renamed:

Previous name	New name
`ids`	`id`
`itemVariationsForItemOptionValues`	`itemVariationsForItemOptionValue`
`itemsForItemOptions`	`itemsForItemOption`
`categoryIds`	`categoryId`
`customAttributes`	`customAttribute`
`enabledLocationIds`	`enabledLocationId`
`productTypes`	`productType`

Link to section
See also

If you need more assistance, contact Developer Support or ask for help in the Developer Forums.

Docs

GraphQL Overview Beta release

This is pre-release documentation for an API in public beta and is subject to change.

Link to section
Supported Square graphs

Link to section
How to access Square GraphQL

Did you know?

Link to section
Get support for Square GraphQL

Link to section
GraphQL basics

Link to section
Queries

Link to section
Filters

Link to section
Required merchant ID filter

Link to section
Variables

Link to section
Using query variables in GraphQL Explorer

Link to section
Pagination

Link to section
Authentication process

Link to section
Setting the access token in GraphQL Explorer

Link to section
Rate limiting for Square GraphQL

Link to section
Return the complexity score for a query

Link to section
How to estimate the query cost

Link to section
Complexity score and page size

Link to section
Limitations

Link to section
Migration notes

Link to section
Catalog graph: Image field changes

Link to section
Orders graph: OrderFilter fields renamed

Link to section
Merchants graph: Merchant ID is passed as a filter

Link to section
Customers graph: CustomerFilter field renamed

Link to section
Catalog graph: Separate entry point for catalog items and merchant ID is passed as a filter

Link to section
Catalog graph: CatalogFilter fields renamed

Link to section
See also

On this page

Docs

GraphQL Overview Beta release This is pre-release documentation for an API in public beta and is subject to change.

Link to section Supported Square graphs

Link to section How to access Square GraphQL

Did you know?

Link to section Get support for Square GraphQL

Link to section GraphQL basics

Link to section Queries

Link to section Filters

Link to section Required merchant ID filter

Link to section Variables

Link to section Using query variables in GraphQL Explorer

Link to section Pagination

Link to section Authentication process

Link to section Setting the access token in GraphQL Explorer

Link to section Rate limiting for Square GraphQL

Link to section Return the complexity score for a query

Link to section How to estimate the query cost

Link to section Complexity score and page size

Link to section Limitations

Link to section Migration notes

Link to section Catalog graph: Image field changes

Link to section Orders graph: OrderFilter fields renamed

Link to section Merchants graph: Merchant ID is passed as a filter

Link to section Customers graph: CustomerFilter field renamed

Link to section Catalog graph: Separate entry point for catalog items and merchant ID is passed as a filter

Link to section Catalog graph: CatalogFilter fields renamed

Link to section See also

On this page

GraphQL Overview Beta release

This is pre-release documentation for an API in public beta and is subject to change.

Link to section
Supported Square graphs

Link to section
How to access Square GraphQL

Link to section
Get support for Square GraphQL

Link to section
GraphQL basics

Link to section
Queries

Link to section
Filters

Link to section
Required merchant ID filter

Link to section
Variables

Link to section
Using query variables in GraphQL Explorer

Link to section
Pagination

Link to section
Authentication process

Link to section
Setting the access token in GraphQL Explorer

Link to section
Rate limiting for Square GraphQL

Link to section
Return the complexity score for a query

Link to section
How to estimate the query cost

Link to section
Complexity score and page size

Link to section
Limitations

Link to section
Migration notes

Link to section
Catalog graph: Image field changes

Link to section
Orders graph: OrderFilter fields renamed

Link to section
Merchants graph: Merchant ID is passed as a filter

Link to section
Customers graph: CustomerFilter field renamed

Link to section
Catalog graph: Separate entry point for catalog items and merchant ID is passed as a filter

Link to section
Catalog graph: CatalogFilter fields renamed

Link to section
See also