# API Paging in HTTP bindings **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [April 26, 2023, 2:27pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924 "2023-04-26T14:27:31Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Cole\_Townsend](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cole_townsend/32/53149_2.png) [@Cole\_Townsend](https://forum.inductiveautomation.com/u/Cole_Townsend)\ **Post date:** [April 26, 2023, 2:27pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/1 "2023-04-26T14:27:31Z")
I am attempting to call for a large amount of data and filter it down into a custom binding in one of my projects with an HTTP binding. I have already applied all the filters that are available for this specific endpoint and the individual calls are limited to 500 values. Does ignitions HTTP binding support any paging abilities to make multiple calls with predefined offsets and then combine that data to then transform? Or is the best bet here to have a separate property binding for each page offset and then combine them how you want? Or make the calls from a gateway-scoped script or something? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 26, 2023, 2:37pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/2 "2023-04-26T14:37:23Z")
> [@Cole\_Townsend](#): > > make the calls from a gateway-scoped script This. ---
**Author:** ![Vignesh\_Muniyasamy1](https://avatars.discourse-cdn.com/v4/letter/v/f08c70/32.png) [@Vignesh\_Muniyasamy1](https://forum.inductiveautomation.com/u/Vignesh_Muniyasamy1)\ **Post date:** [January 13, 2025, 10:24am UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/3 "2025-01-13T10:24:22Z")
I have a requirement on the same line, Now I am planning to expose historical data points through API to external systems. The volume of data is really large in the order of lakhs.. Here are the questions. 1.Can Ignition handle such volume? 2.If so through gateway scoped scripts, how to incorporate pagination mechanisms for data handling? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 13, 2025, 1:25pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/4 "2025-01-13T13:25:49Z")
Exposing an API to outside users requires the WebDev module, and the details of the API operation are entirely up to you. (Ignition can handle substantial data traffic on suitable hardware--both gateway and DB--but I am unsure what "lahks" are.) ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [January 13, 2025, 1:38pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/5 "2025-01-13T13:38:52Z")
I think a lakh = 100,000 (= 105) and is in common use in in Afghanistan, Bangladesh, Bhutan, India, Myanmar, Nepal, Pakistan, and Sri Lanka. It is often used in Bangladeshi, Indian, Pakistani, and Sri Lankan English (according to [Lakh - Wikipedia](https://en.wikipedia.org/wiki/Lakh)). I don't think that _lahkobytes_ are a thing though. ---
**Author:** ![Vignesh\_Muniyasamy1](https://avatars.discourse-cdn.com/v4/letter/v/f08c70/32.png) [@Vignesh\_Muniyasamy1](https://forum.inductiveautomation.com/u/Vignesh_Muniyasamy1)\ **Post date:** [January 13, 2025, 2:45pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/6 "2025-01-13T14:45:23Z")
Yes , 100000 rows of data needs to be exposed and want to do through pagination ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 13, 2025, 3:11pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/7 "2025-01-13T15:11:21Z")
> [@Vignesh\_Muniyasamy1](#): > > do through pagination Ok. Presumably your API will define a start row offset and a quantity in its request payload to accompany the data selection parameters. You would run your query in WebDev, and then construct an abbreviated dataset with the desired rows, then encode that (presumanly JSON) in the reply. You will want to enable caching on your named query so follow-up pages can skip the actual query in common cases. Show your actual API definition if you want more specific assistance. (Also, there are many WebDev topics on this forum that can help you.) ---
**Author:** ![Vignesh\_Muniyasamy1](https://avatars.discourse-cdn.com/v4/letter/v/f08c70/32.png) [@Vignesh\_Muniyasamy1](https://forum.inductiveautomation.com/u/Vignesh_Muniyasamy1)\ **Post date:** [January 15, 2025, 4:57am UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/8 "2025-01-15T04:57:08Z")
Yes Sure, I have historized data in influx db using Kymera module and am trying to expose this data through API end points using web dev module. The volume of data I estimate is really huge and planning to use system.tag.querytaghistory for pulling data from influx historian. Here I want to understand the limitations in 1.system.tag.querytaghistory 2. Web dev response in terms of volume of data it can handle. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 15, 2025, 12:56pm UTC](https://forum.inductiveautomation.com/t/api-paging-in-http-bindings/72924/9 "2025-01-15T12:56:46Z")
You are blazing a trail, I think. You will simply have to test. (I expect the bulk of the workload will be conversions to/from JSON.)