LIVE
listening to the wire…
// simple, ephemeral key-value storage

Put stuff in.
Get stuff out.

No signups. No API keys. No SDK required. Standard HTTP you can call from anywhere.

active keys right now.
ephemeral and unindexed.
you@setget:~ live terminal. type help for commands.

Standard demo keys use a demo- prefix and a one-hour TTL; burn keys use the legacy 365-day maximum. Do not store sensitive production data here.

Core API

all standard HTTP methods.
POST /set/key Store the body. Text or JSON. ?ttl=10m Authorization: Bearer … ?burn=true
GET /get/key Retrieve the stored value by key.
POST /incr/key  /decr/key Atomic increment and decrement with protected-key authorization.
GET /poll/key Long-polling key listener. Blocks until the value updates or times out.
GET /badge/key Dynamic SVG badge for repository READMEs and dashboards.
# quickstart
curl -d "deploy ok" https://setget.net/set/build-4812
curl https://setget.net/get/build-4812

More control with v1

/v1/keys · etags · capabilities

Generate random keys with separate read/write capabilities. Read metadata, update JSON safely with ETags, renew TTLs or delete keys. Opt into an absolute expiration that reads cannot extend.

v1 supports UTF-8 text and JSON up to 50000 bytes. Existing integrations keep their legacy character limits and renewal behavior.

Count. Show. Burn.

history · badges · one-time notes

Opt into bounded UTC counter history, turn values into badges with color thresholds, and wait for changes with polling. One-time messages support an explicit POST consume operation and configurable absolute TTL.

Fine print

how it works.

No accounts

Your key acts as the identifier. Use an optional Bearer password to protect reads and writes. Legacy query passwords still work.

Keys die

Default and maximum TTL: 365 days. Some database-backed reads renew it; cache hits do not. Want it sooner? ?ttl=10m.

Burn after reading

?burn=true. The value is permanently deleted after the first read.

Rate limits

10 requests/second per IP. Requests exceeding limits return 429 Too Many Requests with Retry-After.

It's public

Unprotected keys are public. Use random keys and a password for access control; do not store credentials, PII, or sensitive data.

It's fast

In-memory caching layer backed by persistent storage for low-latency operations.

Need code examples, client libraries, or advanced parameters? View full documentation →