Timestamp API — quickstart

One HTTP call. No key, no account, no signup form. Your file stays where it is — only its SHA-256 travels.

# the current universal time
curl https://beattime.live/api/now/

# stamp a file: hash it locally, send only the hash
sha256sum contract.pdf
curl -X POST https://beattime.live/api/proof/stamp \
     -H 'Content-Type: application/json' \
     -d '{"digest":"<64 hex characters>"}'

That is the whole integration. There is nothing to register, no token to rotate and no quota to negotiate — the service is free and stays free.

What comes back

A stamp answers with the record as it stands right now. Later, the same digest returns more: a signature, then external anchors.

digest
The SHA-256 you sent, lowercase hex. It is the only thing we ever see of your file.
beat
The moment in .beat time — one universal reading, no timezone attached.
utc
The same moment in UTC, to the microsecond.
seq
Position in the append-only log. Numbers never repeat and never move.
week
The ISO week whose Merkle tree this stamp belongs to.
chain_hash
Links this entry to the previous one, so removing an entry would break the chain visibly.
week_root
The weekly Merkle root. Until the week closes it is provisional and still moving.
inclusion_proof
Sibling hashes with their side (L or R). With these you recompute the root yourself — this is what makes the proof independent of us.
root_signature
Ed25519 signature over the frozen weekly root. Appears once the week is sealed.
ots_status
State of the Bitcoin anchor: pending while it waits for confirmation, then bitcoin with the block height.
anchors
Bank references the weekly root was recorded against — an anchor that does not depend on any blockchain.

“Week still open” is the normal answer, not an error.

A fresh stamp has no signature and no anchor yet, because the week it belongs to has not been sealed. That happens at the end of the ISO week; the Bitcoin attestation follows within a day or so. Ask again later with the same digest and the missing fields will be there. Nothing about the recorded time changes in the meantime.

Stamping the same file twice

The first stamp wins, always. Send the same digest again and you get the original record back — same time, same sequence number — with status 200 instead of 201. Retries are therefore safe: a lost response or a nervous client cannot move your timestamp forward.

201 Created   → stamped for the first time
200 OK        → already stamped; the original timestamp is returned
400           → the digest is not 64 hex characters
429           → rate limit; wait and retry

Limits and CORS

Limits are per IP address and exist so that one client cannot crowd out the rest. They are deliberately generous for anything a normal integration does.

EndpointLimit
POST /api/proof/stamp20 / min
GET /api/proof/verify120 / min
GET /api/proof/cert/<digest>10 / min
the rest (time, conversion, sync)300 / min

Every endpoint answers with Access-Control-Allow-Origin: *, so you can call it straight from a browser. Requests through Tor get higher limits, because one exit node carries many people.

Ready-made clients

Single files, no dependencies, Apache-2.0: Python, PHP, JavaScript, C# and C++17. Copy one into your project, or read the full reference.

Get a client   OpenAPI reference

What this is not

Worth knowing before you build on it, and we would rather say it here than let you discover it in review:

The algorithms are written down in the specification, and the desktop client that recomputes all of this is open source.

← Stamp a file in the browser