Expand all | Collapse all

API_DoQuery options skip-n being ignore

  • 1.  API_DoQuery options skip-n being ignore

    Posted 07-31-2020 17:04
    I'm implementing pagination for queries through the API using the API_DoQuery action and the skip-n and num-n options.  For my queries, the API is ignoring the skip-n option.

    The following call returns >3800 records:

    To paginate, I use the options skip-n  and num-n.  But the following API calls return the exact same 500 records:



    That is, the skip-n option seems to be completely ignored, but the num-n option is not, as only 500 records are returned with each of the queries.  Also, if I reverse the order of the options and put skip-n first (i.e. "options=skip-500.num-500"), nothing changes.  Anyone have any ideas?  Thx.

    Brian Yarrington

  • 2.  RE: API_DoQuery options skip-n being ignore

    Posted 07-31-2020 17:12
    Never mind.  No sooner had I posted this than realized there is no "i" in the skip option.  It's working fine now.

    Brian Yarrington

  • 3.  RE: API_DoQuery options skip-n being ignore

    Posted 08-17-2020 21:01
    Glad you got this working, Brian. Have you had a chance to look at pagination in our new RESTful APIs? Would love to hear any feedback!

    Harrison Hersch

  • 4.  RE: API_DoQuery options skip-n being ignore

    Posted 08-24-2020 10:06
    Hi Harrison,

    I have gotten to play a bit with the new API for retrieving reports, and for the most part it works very well.  (Aside: I noticed that "skip" in the new API includes the 'i', which I got a laugh from).  We frequently pull data from QuickBase into other tools (e.g. Excel, R, Python) to run analyses, and using the API to load reports allows us to automate some of the data retrieval.

    So far, I've only noticed two things worth commenting on:
    1. Latency - some times the data retrieval is quick, loading a 2000 x 40 report in a matter of seconds.  Other times the same query will time out with a 30-second timeout set.  This can happen even when the calls to the API happen sequentially.  But we'll notice the same latency issues when we run reports inside of QuickBase, so this is probably not an API issue;
    2. Meta data on summary reports - I am told that for summary reports, all data is converted into either a number or text for display purposes.  We have summary reports that summarize transactions by date.  Because it is a summary report, the date is converted into text, and the meta data from the API indicates the date is text.  I understand why the date is being converted into text for display in QuickBase, but it doesn't make sense that it should be converted to text when sending it to the API.
    Also, the code examples for calling the API in the documentation are a nice addition.  You might want to consider adding R sample code, as well as perhaps a discussion on setting up Postman to interact with the API.


    Brian Yarrington