S3 API

How it works

Buckets, keys, multipart, and presigned URLs are the core. Compatible stores differ on ETag, ACL, and region. A transfer tool that says SFTP cannot speak this API. A tool that says S3 might still fail on a compatible store's missing call.

A job PUTs a 7 GB object with the S3 multipart API to a non-Amazon store. Complete works. A presign call fails because that store wants a different query signature. They upload through the API and share through the store's own link.

How it differs

The S3 API is not SMB and not FTP. Paths are keys. There is no lock.

Compatibility is a claim. Test multipart and presign, not only PUT.

Keep a smoke test.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For s3 api, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive s3 api files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.