Skip to main content
The API has three kinds of limits: how often you may call it, how many people Yungle will email for you, and how big things may be. This page lists each one and what you get back when you reach it.

​
Request limits

Each request counts against two buckets: one for the API key and one for the workspace. The per-key bucket stops one busy integration from starving another in the same workspace. The per-workspace bucket stops extra keys from multiplying what one workspace can do. Going over either returns 429 rate_limited with a Retry-After header in seconds.

​
Read where you stand

Every response after authentication reports both buckets in the RateLimit-Policy and RateLimit headers (IETF draft):
q is the quota and w the window in seconds. r is what is left and t the seconds until that window resets. Throttle on whichever bucket is closer to empty.

​
Monthly call allowance

On top of the rate limits, each workspace has a call allowance over a rolling 30-day window: 50,000 calls on the free plan and 1,000,000 on a paid plan. It exists to stop runaway scripts and sits well above what a working integration uses. Reaching it returns 429 rate_limited with Retry-After: 3600.

​
Requests without a valid key

Requests that fail authentication are counted per IP address: 60 a minute, reported as an "ip" bucket in the same headers. After that, they get 429 rate_limited. A request with a valid key never touches this bucket.

​
Email limits

When you send a transfer to recipients or invite guests to a collection, Yungle emails people on your behalf from its own domain. These limits keep that domain trusted, which keeps your emails out of spam folders. These count email addresses, not requests. Five transfers to ten people each use the same budget as fifty transfers to one person. When a budget runs out, the request returns 429 email_budget_exhausted.
If finalizing a transfer hits the daily recipient budget, the transfer is not sent and stays a draft. Finalize it again without recipients to make the link live, then share the link yourself.

​
Stay under the email limits

  • Send link-only by default. Leave out recipients when you finalize, and hand the returned url to whatever already talks to your client: a project tool, a chat channel, your own email. Link-only sends use no email budget.
  • Use one transfer for many recipients, rather than one transfer each. It costs the same email budget and far fewer requests, and everyone gets the same link.
  • Use webhooks instead of polling for download receipts. See Webhooks.

​
Size and count limits

​
Next steps

Errors

What each error code means and when to retry.

Pagination and idempotency

Walk long lists and retry writes safely.