From 0bbcc28e7af8e271898342d855535172e0e274b6 Mon Sep 17 00:00:00 2001
From: Kevin J <6829515+kmjones1979@users.noreply.github.com>
Date: Fri, 12 Jan 2024 12:30:19 -0800
Subject: [PATCH] typo, lint fix and added details for integers vs strings

---
 website/pages/en/querying/graphql-api.mdx | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/website/pages/en/querying/graphql-api.mdx b/website/pages/en/querying/graphql-api.mdx
index 89cda460d58f..707edf9e9c69 100644
--- a/website/pages/en/querying/graphql-api.mdx
+++ b/website/pages/en/querying/graphql-api.mdx
@@ -104,20 +104,22 @@ Query 10 `Token` entities, offset by 10 places from the beginning of the collect
 }
 ```
 
-#### Example using `first` and `id_ge`
+#### Example using `first` and `_gt`
 
 If a client needs to retrieve a large number of entities, it is much more performant to base queries on an attribute and filter by that attribute. For example, a client would retrieve a large number of tokens using this query:
 
 ```graphql
 query manyTokens($lastID: String) {
-  tokens(first: 1000, where: { id_gt: $lastID }) {
-    id
+  tokens(first: 1000, where: { tokenId_gt: $lastID }) {
+    token_Id
     owner
   }
 }
 ```
 
-The first time, it would send the query with `lastID = ""`, and for subsequent requests would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+The first time, it would send the query with `lastID = ""`, and for subsequent requests would set `lastID` to the `token_Id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+It is important to mention that the works best when filtering based on an entity that is defined as an integer in the schema. You might get unexpected results from strings. 
 
 ### Filtering