plycdn Storage — S3 and Azure compatibility

1Endpoints

Every host is on plycdn.net, and every one of them is served in a region:

{label} is the region's short host label; each region has its own (in-mum for mumbai). It is not the region code (mumbai), which you still use in the API, in billing and as the signing region below; only the host names carry the label, and a host built from the code does not exist. Regions are added over time, so don't keep a list of them in your code or configuration: read the current list, with each region's hosts, from GET /regions. Each item carries an endpoints object with the hosts as patterns:

GET /api/content/v1/regions

{ "items": [
    { "code": "mumbai", "name": "Mumbai, India", "strictCapable": true, "country": "IN",
      "endpoints": {
        "s3": "https://s3.in-mum.plycdn.net",
        "s3VirtualHost": "https://{bucket}.s3.in-mum.plycdn.net",
        "blob": "https://{account}.blob.in-mum.plycdn.net",
        "blobGlobal": "https://{account}.blob.plycdn.net",
        "upload": "https://in-mum.upload.plycdn.com" } }
  ] }

The response lists the regions currently open for new buckets, the same for everyone; only the first is shown here. Replace {bucket} or {account} with your bucket name or storage account name. The dashboard shows the same hosts, filled in, on each bucket's Connect with S3 tools and Connect with Azure tools panels.

A bucket lives in one region, and its S3 and Azure hosts are that region's. Every example in this guide uses mumbai; use your bucket's region instead.

S3: the region your tool signs with

The signing region is the region code (mumbai). Set it wherever your tool asks for a "region". Some tools sign their first call (usually the bucket list) with us-east-1; that is accepted too, as is auto. It changes nothing about security: the signature still needs your secret, and it covers the host name, so a request signed for one region's host cannot be replayed at another.

Any other signing region is refused with AuthorizationHeaderMalformed.

S3: a bucket in another region

A request for a bucket at another region's host is answered 301 PermanentRedirect, with the bucket's region in the x-amz-bucket-region header and the right endpoint in the XML body, as S3 does. It is not forwarded. The AWS SDKs, the AWS CLI and rclone either follow it or tell you which region to use; the fix is to point the tool at the bucket's region.

ListBuckets is the exception: at any region's host it lists every bucket your credential can reach, in every region, each with its BucketRegion.

Azure: storage account, containers and the two hosts

An Azure client addresses a storage account. On plycdn, the storage account is your organization, under a name you choose once:

• 3 to 24 lower-case letters and digits (Azure's own rule, so every tool accepts it), unique across plycdn, and fixed once chosen. A few names are reserved (our own service names and every region code and host label).
• It has a home region, chosen with the name, which you can change later.
• Each sub-organization is its own organization, so it has its own storage account, name and keys.

Choose the name in the dashboard (Developers → Storage credentials → Enable Azure access), or from your backend with POST /storage-account (API reference). Creating the account or changing its home region from code needs an admin API key (a standard key is refused with admin_key_required); reading it works with either. A container is a bucket: its container name is the bucket name.

• {account}.blob.{label}.plycdn.net reaches the containers in that region directly. Use it: it is the one the dashboard shows for each bucket.
• {account}.blob.plycdn.net goes to your home region. A request for a container in another region is forwarded to that region for you, because Azure has no redirect a client follows for writes. It works for every operation, but takes one more hop than the regional host. A request the global host cannot forward unchanged — a blob name with . or .. path segments or raw (not percent-encoded) non-ASCII bytes, or a query that would be re-encoded on the way (even when only the query differs) — is refused there with InvalidResourceName, naming the account's regional host; send it to the regional host, which takes it as received.

Path-style Azure addressing (https://host/{account}/{container}, as local emulators use) is not supported.

Only HTTPS

Plain HTTP is refused. Every response that carries a file also carries Content-Security-Policy: sandbox and X-Content-Type-Options: nosniff, so an HTML file opened from a storage address runs no script. The addresses are on plycdn.net, never on plycdn.com, where the dashboard lives.

2Credentials

S3 and Azure tools sign their requests with a storage credential. It is a separate kind of key from your API key, and it only works on the storage protocols.

Storage credentials are managed by people, in the dashboard only: Developers → Storage credentials. There is no API and no SDK method that creates, lists, rotates or revokes one, and an API key — admin keys included — is refused on those routes with dashboard_session_required.

An Azure credential needs the storage account to exist first (see Endpoints).

Permissions and scope

• A credential reaches all buckets of its organization, including buckets created later, or only the buckets you choose. manage can be given only to an all-buckets credential.
• A credential belongs to one organization and reaches only that organization's buckets. Unlike an API key, a parent organization's credential does not reach its sub-organizations: storage requests carry no organization header. Create the credential in the sub-organization.
• A request needs every permission its operation needs. A missing one is AccessDenied (S3) or AuthorizationPermissionMismatch (Azure).
• A credential can have an expiry date (expiresAt, a time with its timezone offset, such as 2027-01-31T00:00:00Z or 2027-01-31T00:00:00+05:30; a time without an offset is refused). From that moment every request signed with it is refused (InvalidAccessKeyId / AuthenticationFailed), and it cannot be rotated: create a new one.
• At most 20 credentials can be active per organization (credential_limit_reached). Revoked and expired credentials do not count.

The secret is shown once

When you create a credential, the dashboard shows its secret once, with copy buttons and a download as a .env or AWS credentials file. It cannot be shown again, by you or by us. The list shows the access key ID (S3) or slot (Azure), the last four characters of the secret, its permissions and buckets, who created it and when it was last used (updated at most every 5 minutes).

Rotating and revoking

Rotation works like API keys: Rotate creates a second credential with the same name, permissions and buckets, and shows its secret. The old one keeps working until you revoke it:

Only a credential that still works can be rotated: rotating a revoked or expired one is credential_not_found.

1. Rotate, and copy the new secret.
2. Deploy it to the tools and servers that use the old one.
3. When the old credential's Last used stops moving, revoke it.

An Azure account has two key slots, key1 and key2, as in Azure. Rotating fills the other slot, so your application can move to the new key while the old one still works. With both slots in use, revoke one before rotating again.

Revoking takes effect within 30 seconds for every new request, including presigned URLs and SAS tokens signed with the credential. A transfer already streaming finishes. A credential you create or rotate in works at once.

Presigned URLs and SAS

• S3 presigned URLs (SigV4 query signing) work for every operation, with X-Amz-Expires from 1 to 604 800 seconds (7 days), as in S3.
• Azure SAS: service SAS (sr=c or sr=b) and account SAS (ss including b; srt from s, c, o), signed with an account key, on every Azure operation listed here. sv versions from 2020-12-06 up to 2026-06-06 (a newer sv is refused with NotImplemented); st, se, sip and spr are honoured. A SAS lasts at most 7 days, counted from its st, or from the moment of the request when it has no st. Its permissions are limited by the key's: a SAS can never do more than the credential that signed it.
• Not supported: user delegation SAS, stored access policies (si), directory SAS (sr=d), SAS parameters for snapshots, versions or encryption scopes, and the response overrides rscc, rscd, rsce, rscl and rsct: a SAS carrying any of them is refused with NotImplemented, never served with the stored headers instead. Set a file's content type, disposition and other headers when you upload it.

A SAS's permissions (sp) may use only the letters r, l, a, c, w and d. A SAS carrying any other letter — for example racwdlup, which some tools generate by default — is refused with NotImplemented; generate it with only the letters you need. Each letter grants exactly its Azure meaning, and no letter implies another:

Creating a container with a SAS (c or w) or deleting one (d) also needs a signing key whose credential has the manage permission. Blob metadata and property writes (Set Blob Metadata, Set Blob Properties) are not supported with any letter (see "Unsupported").

Which resources a SAS reaches: a blob SAS (sr=b) reaches only that blob's operations; a container SAS (sr=c) reaches its blobs, List Blobs and Get Container Properties, never List Containers or creating and deleting containers; an account SAS reaches the levels in its srt — s for List Containers, c for container operations (creating, deleting, reading properties, listing blobs), o for blob operations.

The SAS is then limited to what its signing key allows: a letter the key's permissions do not cover grants nothing.

Presigned URLs and SAS links work in a browser, but they are not a way to show files to viewers: see "Usage and pricing".

Unsigned requests are refused

Every request must be signed, even to a public bucket (AccessDenied in S3; Azure answers ResourceNotFound to an unsigned request for a supported operation, as it does for anonymous reads of private data; an operation we do not support is answered NotImplemented whether signed or not). A public bucket's files are served at its own address on plycdn.net, not through the storage protocols.

Header-signed requests must be within 15 minutes of our clock (RequestTimeTooSkewed / AuthenticationFailed); keep your machine's clock synchronized.

3Connecting your tools

The examples use the bucket course-media in mumbai, an S3 credential PLYEXAMPLEKEYID23456, and the storage account acmelearning. Keep secrets in your secret store or the tool's own credentials file, never in source code.

AWS CLI

~/.aws/config:

[profile plycdn]
region = mumbai
endpoint_url = https://s3.in-mum.plycdn.net
s3 =
  addressing_style = virtual

~/.aws/credentials:

[plycdn]
aws_access_key_id = PLYEXAMPLEKEYID23456
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY

aws --profile plycdn s3 cp ./intro.mp4 s3://course-media/week-1/intro.mp4
aws --profile plycdn s3 sync ./week-2 s3://course-media/week-2/
aws --profile plycdn s3 ls s3://course-media/week-1/
aws --profile plycdn s3 presign s3://course-media/week-1/intro.mp4 --expires-in 3600

endpoint_url in a profile needs AWS CLI 2.13 or later; with an older CLI, pass --endpoint-url https://s3.in-mum.plycdn.net on each command. The CLI's default checksums (CRC32 on a single upload, a full-object CRC64NVME on a multipart upload) are verified; there is no need to turn them off.

boto3 (Python)

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.in-mum.plycdn.net",
    region_name="mumbai",
    aws_access_key_id="PLYEXAMPLEKEYID23456",
    aws_secret_access_key=secret_from_your_store,
    config=Config(signature_version="s3v4", s3={"addressing_style": "virtual"}),
)
s3.upload_file("intro.mp4", "course-media", "week-1/intro.mp4")   # multipart above 8 MB
url = s3.generate_presigned_url("get_object",
                                Params={"Bucket": "course-media", "Key": "week-1/intro.mp4"},
                                ExpiresIn=3600)

.NET

Plycdn.AspNetCore.Storage.S3 builds an AmazonS3Client (from the AWS SDK for .NET) configured for a region:

dotnet add package Plycdn.AspNetCore.Storage.S3 --version 1.4.0 --source YOUR_PACKAGE_FEED_OR_FOLDER

using Amazon.S3.Model;
using Plycdn.AspNetCore.Storage.S3;

// Recommended: the host label (in-mum) is read from GET /regions, so a new region needs no new package.
// api is your PlycdnStorageApi (server scope); regions are data, never constants.
using var s3 = await PlycdnS3.CreateClientAsync(api, organizationId, "mumbai", accessKeyId, secretAccessKey);
await s3.PutObjectAsync(new PutObjectRequest
{
    BucketName = "course-media", Key = "week-1/intro.mp4", FilePath = "intro.mp4",
});

services.AddPlycdnS3(...) registers the same client (IAmazonS3) for dependency injection, reading the region, host label and credential from your configuration: Region, HostLabel, AccessKeyId and SecretAccessKey in the Plycdn:S3 section (keep the secret in your secret store), or set in code with services.AddPlycdnS3(s => { ... }). The region is a string: pass the code from GET /regions, not a constant. The client connects to the region's host (s3.in-mum.plycdn.net for mumbai) and signs with the region code. The short host label is not built in:

• PlycdnS3.CreateClientAsync reads it from the region's endpoints in GET /regions, so you set nothing. Setting HostLabel (PlycdnCompatOptions.HostLabel) skips the lookup.
• PlycdnS3.CreateClient and AddPlycdnS3 build the client without calling the API, so they need the label from you: copy it from the region's endpoints.s3 in GET /regions (in-mum in https://s3.in-mum.plycdn.net) into Plycdn:S3:HostLabel, the hostLabel argument or PlycdnCompatOptions.HostLabel. Without it they refuse to start with a message that names the setting. The label is not the region code (a host built from mumbai does not exist).

By default the bucket is in the host name (virtual-host style); Plycdn:S3:PathStyle (true) puts it in the path instead. PlycdnStorageEndpoints in Plycdn.AspNetCore.Storage gives you the hosts (S3ServiceUrl(region, hostLabel), S3VirtualHost(bucket, region, hostLabel), BlobServiceUrl(account, region, hostLabel)) if you configure a client yourself.

rclone

rclone is a good way to move a whole library in: from your machine, from another S3-compatible or Azure store, or from anything else rclone reads. Use a current stable rclone.

1. Configure the remote with an S3 credential from the dashboard (Developers → Storage credentials; give it read and write, and delete if you will run rclone sync). In rclone.conf (rclone config file prints where it is):

[plycdn]
type = s3
provider = Other
access_key_id = PLYEXAMPLEKEYID23456
secret_access_key = YOUR_SECRET_ACCESS_KEY
endpoint = https://s3.in-mum.plycdn.net
region = mumbai

• endpoint is the S3 endpoint of the bucket's region, exactly as the dashboard shows it on the bucket's Connect with S3 tools panel (or endpoints.s3 from GET /regions). A bucket in another region needs its own remote with that region's endpoint and code.
• rclone uses path-style addresses by default (force_path_style = true). Both styles are served; add force_path_style = false if you prefer virtual-host style.
• Always point rclone at the plycdn endpoint above, never at any storage address you may have seen elsewhere: only the plycdn endpoint checks your credential, applies the bucket's rules and records the file as a plycdn object.
• rclone's default bucket check (it looks for the bucket before its first upload) works as it is, so there is no need for no_check_bucket. If the bucket does not exist, rclone tries to create it, which needs the manage permission; create buckets in the dashboard instead. A credential without read cannot look, so set no_check_bucket = true for it.

2. Copy, comparing files by checksum:

rclone copy SOURCE:path plycdn:course-media/path \
  --transfers 4 --s3-upload-concurrency 4 --s3-chunk-size 64M \
  --checksum --fast-list --progress

• SOURCE:path is a local folder or any rclone remote.
• --transfers 4 × --s3-upload-concurrency 4 keeps at most 16 transfers open at once, the limit for one client address (see "Limits"); more only earns SlowDown answers, which rclone retries. To go faster, run more machines rather than raising these.
• --s3-chunk-size 64M sends files above 200 MiB (rclone's --s3-upload-cutoff) as multipart uploads in 64 MiB parts. rclone holds transfers × concurrency × chunk size in memory (1 GiB here); lower the chunk size on a small machine, never below 5M.
• --checksum compares size and MD5 to decide what to copy, rather than modification times. rclone records the MD5 of each file it uploads in several parts as metadata, so every file it copied can be checked. Don't pass --s3-disable-checksum.
• An interrupted run can simply be started again: files already there and matching are skipped.

3. Verify:

rclone check SOURCE:path plycdn:course-media/path --fast-list --one-way

rclone check compares every file's size and MD5 on both sides and reports differences; 0 differences found is the result to look for. --one-way checks only that everything in the source arrived. Files uploaded in several parts by another tool have no whole-file MD5 that rclone can read, and rclone check counts them as hashes it could not check rather than as differences.

s3cmd

~/.s3cfg:

[default]
access_key = PLYEXAMPLEKEYID23456
secret_key = YOUR_SECRET_ACCESS_KEY
host_base = s3.in-mum.plycdn.net
host_bucket = %(bucket)s.s3.in-mum.plycdn.net
bucket_location = mumbai
use_https = True
signature_v2 = False

Cyberduck

Open a new connection, choose Amazon S3 (or an S3 profile with a custom server), and set:

• Server: s3.in-mum.plycdn.net, port 443;
• Access Key ID and Secret Access Key: your S3 credential.

Buckets, folders, uploads, downloads, renaming (a copy and a delete) and New Folder all work. Cyberduck's first request is signed for us-east-1, which is accepted.

Any SDK with an S3-compatible mode

Any AWS SDK, or any other SDK or tool with an S3-compatible mode, works with these settings:

For example, with the AWS SDK for JavaScript:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  endpoint: "https://s3.in-mum.plycdn.net",
  region: "mumbai",
  forcePathStyle: true,
  credentials: { accessKeyId: "PLYEXAMPLEKEYID23456", secretAccessKey: secretFromYourStore },
});
await s3.send(new PutObjectCommand({ Bucket: "course-media", Key: "notes.pdf", Body: pdfBytes }));

Azure CLI

export AZURE_STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol=https;AccountName=acmelearning;AccountKey=YOUR_ACCOUNT_KEY;BlobEndpoint=https://acmelearning.blob.in-mum.plycdn.net"

az storage blob upload --connection-string "$AZURE_STORAGE_CONNECTION_STRING" \
  --container-name course-media --name week-1/intro.mp4 --file ./intro.mp4
az storage blob list --connection-string "$AZURE_STORAGE_CONNECTION_STRING" \
  --container-name course-media --prefix week-1/ --output table

BlobEndpoint is what points the CLI at plycdn; without it the CLI goes to Azure. A connection string with a SharedAccessSignature instead of AccountKey works the same way.

To copy a blob, give the source as its plycdn URL with --source-uri. --source-container and --source-blob do not work: the CLI then builds an Azure URL (…blob.core.windows.net) whatever the connection string says, and a copy source that is not a plycdn blob is refused (CannotVerifyCopySource).

az storage blob copy start --connection-string "$AZURE_STORAGE_CONNECTION_STRING" \
  --destination-container course-media --destination-blob week-1/intro-copy.mp4 \
  --source-uri "https://acmelearning.blob.in-mum.plycdn.net/course-media/week-1/intro.mp4"

azure-storage-blob (Python)

from azure.storage.blob import BlobServiceClient

service = BlobServiceClient(
    account_url="https://acmelearning.blob.in-mum.plycdn.net",
    credential={"account_name": "acmelearning", "account_key": key_from_your_store},
    max_single_put_size=64 * 1024 * 1024,   # above this, upload in blocks
    read_timeout=600,                       # committing a large block list takes time
)
blob = service.get_blob_client("course-media", "week-1/intro.mp4")
with open("intro.mp4", "rb") as f:
    blob.upload_blob(f, overwrite=True)

Large uploads go as blocks and end with Put Block List, which assembles the blocks into the file inside the region before it answers — roughly a second for every 250 MB. Keep max_single_put_size at 64 MiB or below, so a large file is sent as blocks (a single Put Blob is limited to 5000 MiB), and raise read_timeout to at least 600 seconds for files of tens of gigabytes, so the client waits for the commit rather than giving up and retrying it. Other Azure SDKs have the same two settings under their own names.

.NET (Azure)

Plycdn.AspNetCore.Storage.AzureBlob builds a BlobServiceClient (from the Azure Storage SDK for .NET):

dotnet add package Plycdn.AspNetCore.Storage.AzureBlob --version 1.4.0 --source YOUR_PACKAGE_FEED_OR_FOLDER

using Plycdn.AspNetCore.Storage.AzureBlob;

var service = await PlycdnBlob.CreateServiceClientAsync(api, organizationId, "acmelearning", accountKey, "mumbai");
var blob = service.GetBlobContainerClient("course-media").GetBlobClient("week-1/intro.mp4");
await blob.UploadAsync("intro.mp4", overwrite: true);

The region code (mumbai) and the label from its listed endpoints give the host acmelearning.blob.in-mum.plycdn.net. Leave out the region to use the global host (acmelearning.blob.plycdn.net), which needs no label. CreateServiceClientAsync reads the label from GET /regions. PlycdnBlob.CreateServiceClient and services.AddPlycdnBlob(...) do not call the API, so with a region they need the label from you: copy it from the region's endpoints in GET /regions (in-mum in https://acmelearning.blob.in-mum.plycdn.net) into HostLabel. AddPlycdnBlob reads Account, AccountKey and, optionally, Region and HostLabel from the Plycdn:Blob section; without a HostLabel next to a Region it refuses to start, naming the setting. The client waits up to 10 minutes for a response, so the commit of a very large file is not sent twice.

4S3 operations

A copy also needs read on the source bucket. Copies never cross regions: a source bucket in another region is refused (InvalidArgument); copy through your machine, or download and upload, instead.

A new bucket is usable at once from your tools, but its storage may take a few seconds more to be ready. Until it is, data calls on it answer 503 SlowDown with Retry-After, which every S3 SDK and tool retries on its own.

Headers accepted because they state what is already true: x-amz-acl: private and bucket-owner-full-control, x-amz-storage-class: STANDARD, x-amz-server-side-encryption: AES256 (everything is encrypted at rest), and x-amz-expected-bucket-owner equal to your organization's ID. Any other value of these headers is refused with NotImplemented. Also accepted, and ignored: x-amz-checksum-mode on GetObject and HeadObject, and x-amz-bucket-object-lock-enabled: false on CreateBucket (true is refused).

Configuration reads answered truthfully. Many tools read a bucket's configuration before they start and treat an error as "broken", so these are answered with what is true on plycdn:

5Azure operations

Block blobs only.

Service and account SAS work on every operation above (see Credentials), with the same headers and conditions as Shared Key, whatever the request is signed with: a header or condition an operation does not support (for example x-ms-delete-snapshots, a lease, or If-Unmodified-Since on Delete Blob) is refused with NotImplemented, never ignored.

A new container is usable at once; until its storage is ready, data calls on it answer 503 ServerBusy with Retry-After, which the Azure SDKs retry on their own.

6Unsupported

Everything below is answered 501 NotImplemented, in each protocol's own error format, with the operation named in the message and x-plycdn-code: operation_not_supported. Nothing is silently ignored.

S3: ACL writes; bucket policies; versioning and versioned requests (versionId); object lock and legal hold; lifecycle writes; tagging writes and x-amz-tagging; replication; website hosting; CORS writes; logging writes; event notifications; inventory; analytics; metrics configuration; intelligent tiering; transfer accelerate; requester pays; ownership controls; public access block writes; SSE-KMS and SSE-C; S3 Select; RestoreObject; POST Object (browser form uploads); SigV2 and SigV4a signatures; WriteGetObjectResponse; directory buckets and session authentication.

Azure: page blobs and append blobs; leases; snapshots; versions; soft delete and undelete; Set Blob Properties, Set Blob Metadata and Set Blob Tier; Set Container Metadata and Set Container ACL; blob and container tags, Find Blobs by Tags; Put Block From URL, Put Blob From URL and Copy Blob From URL; Abort Copy Blob; Query Blob Contents; user delegation keys and user delegation SAS; stored access policies; service properties writes; static website; batch; immutability policies and legal hold; encryption scopes; SharedKeyLite signatures; access tiers other than the default; SAS response overrides (rscc, rscd, rsce, rscl, rsct); and x-ms-content-crc64 (transactional CRC64) on Put Block, Put Blob and Put Block List: send Content-MD5 instead. A SAS whose sv is newer than 2026-06-06 is refused too.

Some of these have a plycdn equivalent: bucket settings, upload rules and delivery restrictions are set in the dashboard or with PATCH /buckets/{bucketId}, and object metadata with PATCH /objects/{objectId} (Storage guide).

7Errors

Each protocol answers in its own format: S3's XML <Error> with Code, Message and RequestId; Azure's XML error with x-ms-error-code. HEAD requests carry no body. Every error also carries our own code in the x-plycdn-code header: match on that, or on the protocol's code, never on the message. Request IDs (x-amz-request-id, x-ms-request-id) are ours; quote one when you contact us.

The codes shared with our own API (bucket_not_found, object_not_found, bucket_name_taken, bucket_not_active, object_exists, object_busy, file_type_not_allowed, file_too_large, plan_limit_reached, checksum_mismatch, size_mismatch, upload_not_open, upload_too_slow, provider_unavailable, bucket_hostname_unavailable, validation_error) mean the same as in the API reference. bucket_hostname_unavailable (S3: 503 ServiceUnavailable; Azure: 503 ServerBusy) means creating the bucket could not finish; retry the create.

8Limits

Every write (PutObject / Put Blob, CreateMultipartUpload, Put Block List, and a copy that replaces the type) refuses a Content-Type that is not exactly one media type (type/subtype with optional parameters, e.g. not video/mp4,text/html) with InvalidArgument (S3) or InvalidInput (Azure); the type part is stored in lower case. Script-capable types such as HTML, XML and SVG are always stored as attachments, even when Content-Disposition: inline is sent.

Bytes of uploads in progress count toward your storage quota until the upload completes or is aborted: a multipart upload's parts and a blob's uncommitted blocks count from the moment each is sent (and stop counting when they expire after 7 days), and completing the upload counts the object once. A part or block that would pass the quota is refused with QuotaExceeded.

Beyond a rate or transfer limit, the answer is SlowDown / ServerBusy with Retry-After, which every SDK backs off on. Leave your tool's retries on. Expect: 100-continue is answered only after your request is authorized and admitted, so a refused upload never sends its body.

9ETags, checksums and consistency

ETags are what S3 tools expect:

• For a file written in one piece (PutObject, Put Blob, a one-part upload through our API, or a copy of one), the ETag is the MD5 of its content, in quotes.
• For a file written in N parts, it is the MD5 of the parts' MD5s followed by -N, as in S3. An Azure blob committed from a block list is such a file, with N the number of blocks in the list (even one), so it has no Content-MD5; an x-ms-blob-content-md5 sent with the list is still checked.
• A file uploaded through the dashboard or our upload API gets the same ETag, so aws s3 sync and rclone check verify it. Azure clients see the same value as the blob's ETag.
• The etag field in our own API's object response is unchanged and can differ from this value; compare S3 and Azure ETags with each other, not with it.

Checksums. Every body's MD5 is computed as it arrives. Content-MD5, the x-amz-checksum-* headers and trailers, the SigV4 payload hash and x-ms-blob-content-md5 are all checked before the file is stored; a mismatch stores nothing (BadDigest, XAmzContentChecksumMismatch, Md5Mismatch). A file written in one piece also gets its SHA-256 recorded as verified.

A request body the signature does not cover is accepted, as S3 accepts it: an UNSIGNED-PAYLOAD or STREAMING-UNSIGNED-PAYLOAD-TRAILER request, or one that carries only a CRC checksum (x-amz-checksum-crc32, -crc32c or -crc64nvme). Every checksum it declares is still checked. What that means for a few small request bodies is under "Security notes".

Consistency. Reads, listings and deletes are strongly consistent, whichever protocol or API wrote the file: a file is listed and readable as soon as its write succeeds, and gone as soon as its delete succeeds. When two writers race on the same key, exactly one wins; a conditional write (If-None-Match: *, If-Match, or Azure's conditional headers) is checked at the moment the file lands, so two conditional writers cannot both succeed. Bucket creation is the one exception (see the note under S3 operations). Delivery links on plycdn.net are cached separately, and refreshed on overwrite and delete as the Storage guide describes.

Metadata and headers. x-amz-meta-* and x-ms-meta-* are the object's metadata (lower-case names, string values), the same field our API reads and writes. A name may use any character an HTTP header name allows, _ and . included (x-amz-meta-my_key, x-amz-meta-a.b). A metadata entry that is not a string cannot be sent as a header; S3 reports how many were left out in x-amz-missing-meta. Content-Encoding, Content-Language, Content-Disposition and Cache-Control are kept with the file and served by delivery links too, and so is Expires for a file written through S3 (Azure blobs have no Expires: it is not kept).

Keys and folders. Keys follow the storage rules: 1 to 1024 bytes of UTF-8, no control characters, no \, no //, no leading /, no . or .. path segment, and nothing beginning with .plycdn- (reserved, in any case, percent-encoded or in full-width letters). Spaces, +, % and non-ASCII characters are fine; use encoding-type=url in listings if your tool asks for it. A key ending in / is refused (invalid_key) except for one case: a zero-byte PUT of a key ending in / is a folder marker, as Cyberduck's New Folder and many consoles create. It lists as a zero-byte object, HEAD and GET answer it (a Range answers the whole, empty marker), and DELETE removes it, as in S3; it is not stored as a file and not charged. Creating one again changes nothing, and If-None-Match: * on an existing one is 412. A marker carries no metadata or object headers (a folder PUT with them is refused, NotImplemented) and is not a copy source (NoSuchKey). An organization holds at most 100 000 of them (QuotaExceeded).

10Security notes

Every request is signed, travels over HTTPS only, and is checked against your credential before anything is read or written. The bodies you upload are checked against every checksum and digest the request declares, and nothing is stored when one does not match.

Some clients do not sign the request body itself, only its headers. The body is then protected by HTTPS and by our servers rather than by your signature. This happens when:

• an S3 client sends UNSIGNED-PAYLOAD (or STREAMING-UNSIGNED-PAYLOAD-TRAILER) with no Content-MD5, or protects the body only with a CRC checksum (x-amz-checksum-crc32, -crc32c, -crc64nvme), which catches accidents but is not a signature;
• an Azure client sends Put Block List with a SAS (a SAS never signs a body), or with Shared Key and no Content-MD5 header.

For file contents, send a checksum or Content-MD5 (current AWS tools send a checksum by default): it is verified as described under "ETags, checksums and consistency". It matters most for four small XML bodies that say what to do:

For these, turn on payload signing (the SigV4 payload hash) or Content-MD5 where your tool allows it. Then the body is bound to your signature: any change to it after you signed is refused (SignatureDoesNotMatch / AuthenticationFailed). Many tools already sign these bodies; some SDKs skip body signing over HTTPS by default and have an option to turn it on. With Azure tools, prefer Shared Key with Content-MD5 on Put Block List, over a SAS, where the tool offers it. DeleteObjects must always carry Content-MD5 or an x-amz-checksum-* header; without one it is refused.

11Usage and pricing

Storage through these protocols is the same storage as through our API: every file counts towards Storage and Uploads exactly as the Storage guide describes, once, whichever door it came in by.

Three more metrics count use of the storage protocols themselves:

• Deletes are not charged: DeleteObject, DeleteObjects, Delete Blob and AbortMultipartUpload (only deleting a bucket or container counts, as a write request). Uploaded bytes are not charged as egress (they are the free Uploads metric). Requests refused before we know whose they are are not counted.
• A request sent to the global Azure host and forwarded to another region is counted once, by the region that served it.
• Figures are counted per bucket, region and UTC day, and settle after the day ends. They appear in GET /usage, GET /usage/resources, on your statement and on the dashboard's Account → Usage page, each with its label. Requests that name no bucket (ListBuckets, List Containers, Get Account Information) are counted against your organization: in GET /usage/resources they carry your organization's ID as resourceId and resourceName: null.

Prices are set per plan and shown on your usage and statement lines (unitPrice). Unless your plan says otherwise, the list prices, the same on every plan, are:

All plans and prices are on Plans and prices.

No allowance is included: the first GB and the first request are charged like the rest.

Reading through the storage API is API access, not delivery. It is uncached, limited per credential, and priced as egress above. It is also not on the delivery path: an outage of the storage protocols never affects playback or delivery links. For viewers, use delivery links on plycdn.net (signed for private buckets); they do not pass through our servers. A presigned URL or SAS link handed to a viewer works, but it is charged as storage API egress, and it has none of delivery's caching, referrer rules or country rules.