Skip to main content

​
Success

The API does not use 201 for uploads. Do not require it.

​
Client errors

​
400 is broader than validation

A 400 can mean:
  • the JSON body failed schema validation,
  • an unknown field was sent to a strict schema,
  • a multipart upload had no file part,
  • the owning user has no active encryption keys,
  • a destination folder does not belong to the destination bucket,
  • a folder move omitted a required destination,
  • a folder tree exceeded the depth limit.
Read the message for diagnosis, but branch on the status.

​
403 needs a second look

A 403 is not one condition. Check for a stable code first:
  • API_COMPANY_ONLY — individual account
  • API_KEY_SURFACE_DENIED — route family not allowed
  • API_BUCKET_SCOPE_DENIED — bucket outside key scope
  • DEVICE_BLOCKED — backup device blocked
If there is no code, assume a missing capability or a retention/legal-hold block.

​
Server errors

In production, 5xx messages are replaced with a generic message. Do not expect schema or driver details.

​
Status codes that are not part of the contract

The API does not document 201, 202, 204, 304, 405, 406, 409, 415, 422, or 428 as stable outcomes for the published endpoints. If you observe one, treat it as an undocumented edge case and report it.
Version operations other than downloads, and the file-restore endpoint, can return HTTP 200 while the inner data.status is 400, 404, or 410. See Versions and restore.

​
Mapping to user experience

​
Logging

Log:
  • HTTP status,
  • stable code,
  • route template,
  • timestamp,
  • your request ID,
  • latency.
Do not log:
  • X-Secret-Key,
  • full signed URLs,
  • file contents,
  • personal data from file names unless your policy allows it.