Offset value invalid; output does not match API documentation

[Bastiaan_Bijl]

Hello,

I am trying to build a query in Power Query/Power BI to load an Airtable table into the data model. I have found some working code which uses the offset parameter returned by the API to deal with the pagination.

However, the offset value returned does not match the API documentation and gives an error when I try to parse it.

According to the API docs, the offset should look like this:

"offset": "reco1XxXxXxXxXxXxXx"

However, what I get is this:

"offset":"itrZXxXxXxXxXxXxXxXx/rec5XxXXXxXxXxXxXx"

When I parse the value into the URL, using &offset=itrZXxXxXxXxXxXxXxXx/rec5XxXXXxXxXxXxXx, I get the following error:

{"error":{"type":"LIST_RECORDS_ITERATOR_NOT_AVAILABLE"}}

When I try passing either of the values (before and after the /), then the error is:

{"error":{"type":"INVALID_OFFSET_VALUE","message":"The value of offset itrZXxXxXxXxXxXxXxXx is invalid"}}

Am I missing something here?

Thanks!

[Bastiaan_Bijl]

Bill.French:

And that’s my point - you didn’t share the complete picture until now. Without a complete picture of the logic, it’s almost impossible to assess what’s truly happening.

Well, if you scroll back up in the post, the entire code I used 5 days ago was there. When testing this morning, I actually copied it from the post because I did not save it anywhere else. :slightly_smiling_face:

As such, I conclude the exact opposite; it’s extremely likely something in your code probably changed and it started working.

Show of hands - how many API developers have experienced unexplained “sudden” success with an unfamiliar API? :winking_face:

No worries though - it’s great you have a working model now.

I guess we will never know, so let’s agree to disagree on this point. :winking_face: After all, it is indeed nice to have a working model now.

One last thing: I still get the itrXXXXXXXXXXXX back as part of my offset value. Do you get that as well now?

[Bill_French]

Bastiaan_Bijl:

I guess we will never know, so let’s agree to disagree on this point.

I definitely want to agree that we disagree. :winking_face:

We version every change when testing new API code. This allows us to know where we may have created issues and more important where APIs are actually failing.

Sure, it’s a little more effort, but the analytics we get from this process accelerate development in the long run and put us in a position where we never feel like we will never know why things failed. This also provides us with clear ammunition to assert claims of another API failing to perform, an important development aspect that allows us to bill for time spent on failures beyond our control.

Bastiaan_Bijl:

I still get the itrXXXXXXXXXXXX back as part of my offset value. Do you get that as well now?

It’s difficult to say; when stuff works reliably we don’t go looking at offset values that have likely been occurring properly for years. I do know that in many API unit tests recently I have seen only record IDs, not iteration ids. But we must also realize unit tests are designed to produce responses in very narrow ranges of data.

But without question, of the 80+ Airtable API integration processes currently running under our apps every minute, we have seen zero failures from Airtable over the recent past (9+ months) with one exception - an Airtable outage that occurred about two weeks ago. The API impact was very brief (like 2 minutes) while the UI was impacted for a few hours I think.

[aaron_altamura]

Hey Guys,

Just wanted to say thank you all for this post!

I am getting the same response ‘itrXXXXXX/recXXXXXX’ for the offset and was unsure how to incorporate with the curl. This had been bugging me for a number of days now!

I used your query to better understand how to properly query for the next page with python’s api requests library: ‘offset’: ‘itrXXXXXX/recXXXXXX’

Glad to be amongst some fellow geeks :grinning_face_with_big_eyes:

[Shahbaz_Haidar]

In case anyone is still getting the issue, here is what happened with me.
I was getting same error and was making changes here and there but nothing worked. Then I realized, because of iterative offset value, my url was getting elongated every time as it was not replacing old offset but appending in it.
If you are still getting this error, just print your URL just before hitting API and see if it is OK.

[candle]

In case this helps anyone coming across this issues now...

I was having this issue when running the query in postman, and it ultimately came down to quotation marks.

I thought I had to pass the offset surrounded by quotes, e.g.,

&offset="itrXXXXXX/recXXXXXX"

I kept getting the error.

When I removed the quotes and passed,

&offset=itrXXXXXX/recXXXXXX

I got a proper response and no error.