GraphQL API Rate Limits and Query Cost

This article explains the GraphQL query cost limits and REST API rate limits for Telematics Guru. 
 

Current Limits

The REST API limit is 100,000 requests per hour, per user. Where there is no user context, the limit is 100,000 requests per hour, per source IP address.
 

For GraphQL, a single query can have a maximum cost of 4000, and each organisation has a budget of 15,000 GraphQL cost units per 15 minutes.
 

GraphQL Paging

GraphQL paging is applied per request. The default page size is 100 items, and the maximum page size is 500 items.
 

How GraphQL Cost Works

GraphQL cost is based on the fields, filters, sorting, and nested data included in a query. The schema assigns weights to many fields and arguments, and those weights contribute to the total query cost.
 

Where a field has no specific cost defined, the default cost is 1.
 

Cost Response Headers

Every GraphQL response includes headers that show the cost of the query you just ran and how much of your organisation's budget remains. You can use these to monitor your usage and design your integration to stay within the limits.
 

x-graphql-cost-charged is the cost of the query that was just executed.

x-graphql-cost-limit is the organisation's total cost budget for the current window.

x-graphql-cost-organisationid is the organisation the cost was charged against.

x-graphql-cost-remaining is the cost budget remaining in the current window.

x-graphql-cost-reset-seconds is the number of seconds until the budget window resets.
 

For example, a response with x-graphql-cost-charged: 102, x-graphql-cost-limit: 15000, x-graphql-cost-remaining: 14898, and x-graphql-cost-reset-seconds: 900 means the query cost 102 units, leaving 14,898 units available until the window resets in 900 seconds.
 

What Usually Drives Cost Up

Page size increases cost because more returned items means the field selection is repeated across more records.

Nesting increases cost because each returned item can include more related objects and more weighted fields.

Field selection increases cost because some fields are weighted more heavily than others.

Filtering can help reduce cost by reducing the result set, although filter operations can also carry their own weight.

Ordering is also weighted in the schema, but it is usually not the main reason a query becomes expensive.
 

Examples of Field Weightings

The schema includes examples of both light and heavy fields. The weightings and example costs below are current as of 7 July 2026 and may change as the schema evolves.
 

assets, events, and other top-level connection fields are weighted at 10.

where and order arguments are commonly weighted at 10.

totalCount on connection types is weighted at 10.

Asset.lastLatitude and Asset.lastLongitude are weighted at 1.

DeviceData.dateTimeUtc, DeviceData.latitude, and DeviceData.longitude are weighted at 1.

EventLog.telemetry is weighted at 10.

TelemetryModel.latitude and TelemetryModel.longitude are weighted at 10.

String filter operations such as contains, startsWith, and endsWith are weighted at 20.

Several TagData fields such as batteryVoltage, dateTimeUtc, gwLatitude, and gwLongitude are weighted at 10.
 

Example: Lightweight Query

A small asset query that requests a limited number of records and only low-cost fields will usually stay well under the limit.

query {
  assets(organisationId: 123, first: 10) {
    nodes {
      assetId
      name
      lastLatitude
      lastLongitude
    }
  }
}

This stays relatively light because the page size is small and the selected location fields are weighted at 1 each.

Approximate cost: 51. The assets field costs 10, plus 4 per returned asset (four fields at 1 each) multiplied by the page size of 10, plus 1 for nodes.
 

Example: Adding Filters and Counts

This query is more expensive because it adds a filter and requests the total count as well as the result set.

query {
  assets(
    organisationId: 123
    first: 10
    where: { name: { contains: "truck" } }
  ) {
    totalCount
    nodes {
      assetId
      name
      lastLatitude
      lastLongitude
    }
  }
}

In this case, the top-level query, the where argument, the contains operation, and totalCount all add cost before the returned fields are even considered.

Approximate cost: 91. The assets field costs 10, where adds 10, contains adds 20, totalCount adds 10, plus 4 per returned asset multiplied by the page size of 10, plus 1 for nodes.
 

Example: Nested Data Increases Cost Faster

Nesting is one of the quickest ways to increase cost because the selected child fields are repeated for every returned record.

query {
  assets(organisationId: 123, first: 10) {
    nodes {
      assetId
      name
      lastTripData {
        dateTimeUtc
        latitude
        longitude
      }
    }
  }
}

This query is still manageable at a small page size, but it is heavier than the basic asset query because each asset can now return additional weighted fields from lastTripData.

Approximate cost: 71. Each returned asset now costs 6 (two asset fields, the lastTripData object, and its three nested fields at 1 each), multiplied by the page size of 10, plus 10 for assets and 1 for nodes.
 

Example: Heavier Nested Telemetry

The events query below is a stronger example of how a nested field can increase cost more quickly.

query {
  events(
    organisationId: 123
    startDateUtc: "2026-06-01T00:00:00Z"
    endDateUtc: "2026-06-02T00:00:00Z"
    first: 10
  ) {
    nodes {
      eventId
      eventDateUtc
      telemetry {
        latitude
        longitude
      }
    }
  }
}

This is heavier because EventLog.telemetry is weighted at 10, and the nested telemetry latitude and longitude fields are also weighted at 10 each.

Approximate cost: 331. Each returned event costs 32 (eventId and eventDateUtc at 1 each, plus telemetry, latitude, and longitude at 10 each), multiplied by the page size of 10, plus 10 for events and 1 for nodes. Note that omitting first would apply the default page size of 100, which pushes this same query past 3200, and increasing the page size beyond that would exceed the 4000 limit.
 

Example: Tag Data Can Become Expensive Quickly

Queries that include tag data can also add cost quickly when several weighted fields are selected together.

query {
  assets(organisationId: 123, first: 10) {
    nodes {
      assetId
      taggedAsset {
        lastDateTimeUtc
        lastTagData {
          batteryVoltage
          dateTimeUtc
          gwLatitude
          gwLongitude
          temperatureCelsius
        }
      }
    }
  }
}

This is more expensive than a simple asset query because several of the selected tag fields carry explicit weights, and they are nested under each returned asset.

Approximate cost: 561. Each returned asset costs 55 (lastDateTimeUtc, batteryVoltage, dateTimeUtc, gwLatitude, and gwLongitude at 10 each, temperatureCelsius at 2, and 3 for the remaining fields and objects), multiplied by the page size of 10, plus 10 for assets and 1 for nodes. At the default page size of 100 this query would exceed the 4000 per-query limit, so always set an explicit page size on tag data queries.
 

How Query Cost Limits and Rate Limits Work Together

A single GraphQL query is limited to a maximum cost of 4000. In addition, each organisation has a rolling budget of 15,000 GraphQL cost units per 15 minutes.
 

This means that even if individual queries stay under the per-query limit, running many high-cost queries in a short period can exhaust the organisation's cost budget. If the budget is exceeded, further GraphQL requests will be limited until the window resets. Use the x-graphql-cost-remaining and x-graphql-cost-reset-seconds headers to track your remaining budget, and keep queries lean by selecting only the fields you need.
 

Summary

REST API limit is 100,000 requests per hour, per user.

Where there is no user context, the limit is 100,000 requests per hour, per IP address.

GraphQL default page size is 100 items.

GraphQL maximum page size is 500 items.

GraphQL maximum cost is 4000 per query.

Each organisation has a budget of 15,000 GraphQL cost units per 15 minutes.

Every GraphQL response includes x-graphql-cost headers showing the cost charged, the budget remaining, and when the window resets.

Page size, nesting, and field selection are the main factors that increase cost.

Filtering can help reduce returned data, but filters can also add cost.

Ordering contributes cost in the schema, but it is usually not the main cost driver.
 

Next Steps

Build your first GraphQL query by visiting GraphQL API for Telematics Guru