Crates

Crates endpoints work on the account’s StorageCrates, with a full access key or a key scoped to the crate. A crate is named by its handle (like c7xk2m9p), its logins by their full name (the master login is the handle; a sub-user is <handle>-<folder>), and SSH keys by their SHA256 fingerprint.

Reads (every GET) need the scope’s read permission; everything that changes something needs write. A crate that isn’t on the account is 404; a key without the permission gets 403. While the service is suspended or cancelled the crate can be read but not changed (403), and snapshot changes need a plan that includes snapshots (403).

Changes go to the crate’s storage node first and are saved only once it has them. When the node refuses a change it answers 400 with the node’s reason; when it can’t be reached, 502, and nothing changed: try again shortly. The plan sets how many sub-users and snapshots a crate may have, and going over is refused with 400.

Passwords are generated, never chosen: adding a sub-user or asking for a new password returns it once, and it can’t be read back later.

Units: size_gb is a size cap in GB, used_gb what’s stored in GB (updated through the day, not live), and a snapshot’s used_bytes what deleting it would free, in bytes.