#Damir-BigQuery
wicked finch
Hi there! Can you tell me more about what is blocking here? Why do you need a more specific timestamp than the created UNIX?
wanton quiver
If I take charges made between 17:52:02 and 17:52:02 next day, I am not sure where the charges made at the exact time (17:52:02) are gonna go.
wicked finch
Well I think you would retrieve between 17:52:02 and 17:52:01 the next day?
You would need to decide on that.
wanton quiver
It's the same problem. Those bordering values are always gonna be the issue because the timestamp is not precise enough (unique per row).
And I am not sure how the sorting goes on Stripe side, that can help also. If the list is sorted by the time created I can always take the last id and use **starting_after ** cursor. But the problem on that approach is because I would not be able to know what is the last id in the data warehouse side because the sort by created field is going to be different than Stripe's.
wicked finch
Sorry server is busy.
The better way to do this is to actually list by created.gte or created.lte: https://stripe.com/docs/api/charges/list#list_charges-created-gte
That will ensure you are grabbing all border values
wanton quiver
Then I am going to pull some duplicated data
It's the same as going back/for a day before/later
Actually no problems here
When I think about it, I will always pull the data a day later, for a day before. So no new rows can appear in the set.
Thank you so much for your help!
Do you maybe know if there are some restrictions in number of API calls, or amount of data transfered?
wicked finch
There are rate limits you should be aware of: https://stripe.com/docs/rate-limits