Documentation
TTL policy
Every Cacheify key always has a TTL. "No expiry" is not a state a key can hold — forgotten keys cannot quietly accumulate on someone's Redis server.
The default: 24 hours
Any write without an explicit expiry — plain SET, INCR, APPEND, LPUSH, RPUSH, SADD, HSET, ZADD — receives the platform default TTL of 24 hours, stamped by the server, not by your client.
If a value must outlive a day, either arm EX / expiresInMs on the write itself, or re-arm it after:
curl -X POST https://cacheify.bot-keep.xyz/api/data/$DB_ID/keys/session:9942/expire \
-H "Authorization: Bearer $RK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"expiresInMs":86400000}'Rules for both transports
| Request | Result |
|---|---|
| Plain write (no expiry) | Stored with the 24 h default TTL |
| Write with EX/PX/SETEX/PEXPIRE (gateway) or expiresInMs (HTTP) | Stored with exactly that TTL |
| POST /keys/{key}/expire (HTTP) or EXPIRE (gateway) | Re-arms the TTL on an existing key |
| PERSIST — both transports | Refused (HTTP 422 ERR_VALIDATION / Redis error reply): removing an expiry would create an immortal key |
| Read of an expired key | 404 ERR_NOT_FOUND (HTTP) or nil (RESP); the key is gone server-side |
The countdown lives on the server: when it reaches zero the key is already gone on the next read. There is no sweeper to run, no cron to set, no application-side expiry logic. GET /keys/{key} returns ttlMs so UIs can render countdowns without extra calls — and TTL key does the same over RESP.
Identical on both planes
The engine enforces these semantics before executing any command, so behavior is the same whether the backing store is the embedded engine or a real Redis server — and whether you arrived over HTTPS or RESP. Write your values with this in mind: countdown-style tokens that should outlive a day need their TTL armed explicitly, every time.