Limits per end user

Give each end user of your app a filesystem with its own monthly spend cap, operation rate and storage quota, set from your backend.

When you put Mountable inside your app, give each end user their own filesystem. Your backend sets that filesystem's limits through the API, and Mountable enforces them for mounts and the files API alike. One heavy end user stops at their own limit; your other end users keep working.

The limits

Your organisation's own limits still apply on top: its monthly spending cap and the quotas. Filesystem caps can add up to more than the organisation cap; whichever is reached first stops the work. Changes apply to the next operation, including mounts and sessions that already exist.

Create an end user's filesystem with its limits

Set the limits when you create the filesystem, so there is never a moment without them. Use an API key that is not limited to one filesystem; the key gets a read-write grant on the new filesystem.

curl -X POST https://mountable.io/api/v1/orgs/$ORG_ID/filesystems \
  -H "Authorization: Bearer $MOUNTABLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "user-42", "spending_cap_cents": 500,
       "mutations_per_minute": 120, "byte_quota": 5368709120,
       "entry_quota": 50000}'

This end user can spend at most $5.00 (or €5.00) a month, make 120 changes a minute, and store 5 GiB in 50,000 entries.

Change them later

PATCH changes only the fields you send. null removes a spending cap or a custom rate.

curl -X PATCH https://mountable.io/api/v1/orgs/$ORG_ID/filesystems/$FS_ID \
  -H "Authorization: Bearer $MOUNTABLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"spending_cap_cents": 2000}'

GET /api/v1/orgs/{org_id}/filesystems/{fs_id} shows the limits. GET .../usage adds reserved_cents and currency: how much of this month's cap the filesystem already uses, so you can show the end user what is left.

How the spend cap counts

The cap works like the organisation cap, for this one filesystem. Files keep costing money after a worker disconnects, so the filesystem reserves a full month at its highest stored size and file count this month, plus its downloads. An upload reserves room before it starts and returns what it did not use. Deleting files does not free this month's peak. Each of the three charges rounds up to a whole cent, so a cap can admit a little more work before the next cent is reached.

A cap below what the filesystem already reserves is refused with 409 spending_cap_below_reserved and the minimum_cents you can set. A saved payment method is required, because caps are in your billing currency.

Stored files are never deleted when a limit is reached. Usage beyond it is refused:

When both caps are reached, you get the organisation code: raising the end user's cap would not help.

Who can change limits

• Owners and admins.
• An API key that is not limited to one filesystem, while the person who created it is an owner or admin, on a filesystem it has a read-write grant on.
• Not a key limited to one filesystem: hand that key to the worker that serves one end user, and it cannot raise its own limits (403 key_limited_to_filesystem).

The organisation's spending cap can only be changed by a person on the Billing page; no API key can raise it.

How many end users fit

An organisation's filesystems together reserve at most 200 GiB and 2,000,000 entries. A filesystem reserves its quota, or what it already stores if that is more, so smaller quotas fit more end users: for example 200 end users at 1 GiB and 10,000 entries each. A create or a quota increase that does not fit is refused with 409 filesystem_quota. Contact support if your app needs more.

The mountable CLI, MCP server, SDKs and console do not set these limits yet; use the REST API.