COPY API rate limit error in Quickstart
See original GitHub issueWhen running through the Quickstart Guide, I hit a COPY API rate limit error at this step: https://github.com/CartoDB/cartoframes/blob/develop/docs/developer-center/guides/04-Quickstart.md#publish-and-share-your-results
where it says to put both to_carto
calls in the same cell:
stores_cdf.to_carto('starbucks_stores', if_exists='replace')
isochrones_cdf.to_carto('starbucks_isochrones', if_exists='replace')
I guessed that if I separated them into separate cells and waited for the first to complete before starting the next, that I would be within limits and OK. Doing this I was successful!
I’d PR the docs themselves, but maybe we are looking at changing the COPY endpoint limits to better accommodate use patterns like this?
Issue Analytics
- State:
- Created 4 years ago
- Comments:13 (12 by maintainers)
Top Results From Across the Web
Rate Limiting - Docs - NFTPort
NFTPort employs rate limits as safeguards so that the API stays stable under traffic spikes. The 429 HTTP status code shows up if...
Read more >Shopify API rate limits
If an app reaches API rate limits for a specific resource, then it receives a 429 Too Many Requests response, and a message...
Read more >Rate Limits - Trello - Atlassian Developer
There is a limit of 300 requests per 10 seconds for each API key and 100 requests per 10 second interval for each...
Read more >Quickstart API Error Handling - Zuora
Check our Quickstart API Reference or the returned error message to see which values are permitted ... See our rate limit documentation for...
Read more >Rate Limits on the Airthings API
If a client exceeds the rate limit, the API will respond with status code: 429 and the below mentioned response body and header...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This might affect also the COPY use in Kepler integration. Thx for keeping us up-to-date. Just a reflection we made about ‘request retry’: a retry is safer to get the final result, but it could add a ‘slowness perception’ to the user, and perhaps it would be nice to notify him (or even break) during the process because of that limit hit. That way the user could consider another options (like a better plan).
Adding @VictorVelarde for visibility