APPSINITYRate limits
No Appsinity service counts your requests. There is no throttle, no quota and no 429 from the application. The limits that do exist come from request size, gateway timeouts, credential lifetimes and row-fetch caps.
Open Appsinity StudioWhat is not limited
| Mechanism | Status | Evidence |
|---|---|---|
| Requests per IP | None | No throttle middleware in the service |
| Requests per account | None | No per-user counter exists |
| Concurrent connections | None at the app | Only the web server and CDN shape it |
| Payload size per request | Not enforced for JSON | Size caps apply to uploads only |
| Response rate 429 | Never returned by the app | Statuses used are 200, 201, 400, 401, 403, 404, 409, 500, 502 |
| Burst protection on login | None documented | Credential stuffing is defended only by password policy |
| Daily quota | None | No quota state is kept |
The limits that do bind
| Limit | Value | Where it bites |
|---|---|---|
| Session token lifetime | 30 days | Long-running automation dies mid-task |
| Presigned PUT expiry | 10,800 seconds | A very slow large upload |
| Build upload ceiling | 5 GiB per object | One file, not one build |
| App media ceiling | 250 MiB per object | A large trailer or artwork file |
| Gateway timeout | 60 seconds | A synchronous sign request answers 504 while the work continues |
| Reviews fetched | 100 rows | A listing with more reviews than that |
| Analytics sources | 20 rows | Long-tail traffic origins |
| Country breakdown | 50 rows | Small-market detail |
| Catalog fetch ceiling | limit=100 | Anyone enumerating the store |
| Browse and chart caps | 60 items | Category pages |
| Search pool | 100 rows, 6 shown | Search result depth |
| New-release window | 45 days | What counts as new |
| Auto-signer cycle | 30 seconds | How quickly a build gets signed |
| Licence devices | 2 per licence | Install attempts beyond that |
| Offline grace | 72 hours | A machine without connectivity |
| OTP validity | 10 minutes | A slow copy-paste |
What overload actually looks like
- 500s from the application when a handler throws, rather than a polite refusal.
- 502 from the payments Worker when Razorpay itself is slow or rejects the order.
- 504 from the gateway when a synchronous call crosses sixty seconds.
- Silently stale reads, because the store pages and asset sheets are cached at the edge for hours.
- Nothing that says slow down. You have to decide that yourself.
Advice, stated as advice
- Cache your own reads. Analytics aggregates change slowly; a daily fetch is usually enough.
- Poll with a cursor. Read once, compare against the last value you acted on, sleep longer when nothing moved.
- Never loop on 500. One retry after backoff, then surface the error. Three hundred retries of a broken handler is a self-inflicted outage.
- Batch through the catalogue. Fetch
limit=100once and filter locally instead of requesting per listing. - Front your own traffic. If you build a mirror or a widget, cache it server-side. Players hitting your page should not each hit Appsinity.
Frequently asked questions
What is my rate limit?
None is defined or enforced at the application layer, so there is no number to exceed and no header reporting one. Practical ceilings come from payload sizes and timeouts.
I got a 429. Where from?
Not from these services. A 429 on an appsinity.com URL comes from the CDN or edge in front of it, which means your path is being throttled as abusive traffic.
Can I get a higher limit?
There is no tier, key or plan to raise. Volume agreements are a conversation with the platform, not a configuration.
Why did my sign request 504 but still work?
The gateway gave up at sixty seconds while the signing job continued server-side. Poll the listing for signingStatus rather than trusting the HTTP response.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]