API limits on Personal Plans?

We don't have any specific numbers documented for the general rate limiting system. It is only designed to prevent abuse though, and is accordingly relatively generous. Further, the limits operate on a per-user basis. That being the case, you generally don't need to worry about hitting it in normal use.

Also note that not all 429s and 503s indicate rate limiting, but in any case that you get a 429 or 503 the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not.

In my experience Josh, these rate limits are very very high. They also apply to business and personal equally. (Business just gets another extra rate limit) They seem only intended at stopping just blatant abuse or get triggered by atomoticty requirements when uploading files. Just wait for the retry-after period specified in the response and you can request again. Seems to be on the order of seconds. (Business file rate limits are a different thing, maybe worth a different name for clarification. They would require you wait until the start of the next month...)

They're actually so high, it's hard to hit them when testing so you might only realize you need to handle them when your app starts running in production =)

To try and observe them first hand to test your app, try uploading 30 files to the same user directory in parallel requests and you'll hit a server type of rate limit. Specifically this kind: https://github.com/dropbox/dropbox-api-spec/blob/master/auth.stone#L27

(That links to the raw specification that Dropbox uses to autogenerate SDKs and documentation. Super cool they can describe a new API call there and all the language bindings just update to use it. It does explain some of the mechanical consistency in Swift though. It's sort of like Swagger, but Dropbox style...And I appreciate not having to read 6 layers nested JSON)