MOmoda
uploads

Get Upload Limits

Changed on

Machine-readable upload size limits.

Exists so a client can route (or refuse) BEFORE sending bytes: the gateway rejects an oversized POST /uploads with a bare 413 that carries no limit and no envelope, so the ceiling is not discoverable from the failure itself.

max_file_bytes is per-caller, not per-deployment since ENG-6169 — a non-paying workspace gets the free-tier ceiling. It has to be resolved the same way the upload handlers resolve it, or this endpoint advertises a limit the very next request refuses, which is worse than not publishing one at all. Cache it per API key, not globally.

get/uploads/limits

Request

  • Base URL
    https://api.moda.app/v1
  • URL
    https://api.moda.app/v1/uploads/limits
  • Auth
    HTTP bearer

Headers

Moda-Version'2026-04-12' | '2026-05-01'
Example:2026-05-01

Calendar-dated API version pin. New integrations should pin 2026-05-01 to opt into the newest response shapes. For back-compat the server also accepts requests with no header and resolves them to the current default (today: 2026-04-12); that default advances on each sunset date. Any unsupported value returns 400 unsupported_version.

Response

Successful Response

max_direct_upload_bytesinteger required

Hard request-body ceiling for the multipart POST /v1/uploads lane (the API gateway's HTTP/1 cap; currently 32 MiB = 33,554,432 bytes). Requests above it are rejected with a bare, envelope-less 413 before reaching the app. Route larger files through the signed-URL flow (POST /v1/uploads/url + PUT + POST /v1/uploads/register); staying a margin below this number is wise since multipart framing counts toward it.

max_file_bytesinteger required

Maximum stored file size on every upload lane, for THIS API key's workspace. A paid workspace gets the deployment ceiling (currently 250 MB, matching the in-app uploader); a free workspace is capped lower. Enforced on actual bytes — at register time on the signed-URL flow — with a typed upload_too_large 413. Because it varies by plan, cache it per key and re-read it after a plan change.

max_file_bytes_is_plan_limitboolean

True when max_file_bytes is this workspace's PLAN ceiling rather than the deployment maximum — i.e. a paid plan would raise it. Clients that refuse a file locally should branch on this: naming an upgrade alongside 'shrink the file' is the only remedy that exists for a free workspace, and a bare number offers none.

Example response

{
  "max_direct_upload_bytes": 33554432,
  "max_file_bytes": 262144000
}

Changes