The first decision in Cacheify was not which Redis engine to embed. It was how an application should reach that engine. The answer here is HTTP + JSON, and it has consequences worth stating plainly.
The contract
Every data call is an HTTP request. A command endpoint accepts a command name and an argument array, then returns the same envelope as the rest of the platform: success, data and optional metadata. The command console in the dashboard calls the same endpoints your service calls.
That means fetch, requests, Invoke-RestMethod and curl are enough. There is no RESP handshake, no persistent socket to keep alive between serverless invocations, and no driver version to match against the platform.
curl -X POST "$CACHEIFY_BASE_URL/api/data/$DB_ID/command" \
-H "Authorization: Bearer $CACHEIFY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"command":"SET","args":["session:9942","active","EX","3600"]}'Why not RESP
RESP is excellent when you control a long-lived process near the cache. It is awkward when the caller is an edge function, a scheduled job, a browser-backed tool or an AI agent that already knows how to make an HTTPS request and nothing else.
Serving RESP over the same HTTPS surface would also mean asking every user to open an outbound TCP port, manage client libraries and reason about connection pooling - a class of support questions with nothing to do with the data model. That argument holds for the data plane, and the platform answers it honestly: the HTTP surface stays, and native clients get a separate RESP gateway on their own address.
The trade-offs
HTTP is not a drop-in replacement for RESP, so the platform stopped pretending it could be one: native Redis clients do not talk to the HTTPS API. They get their own door - a RESP gateway whose AUTH password is your database API key (redis://:<API-key>@<gateway-host>:<port>/0). RedisTemplate, ioredis and redis-py connect unmodified to the same key space, with the same command surface and the same mandatory expiry as the HTTP plane.
Blocking commands and pub/sub subscriptions do not fit either contract and stay outside the supported surface: roughly sixty Redis-compatible commands across strings, lists, sets, hashes and sorted sets, plus cursor-based key browsing. Pipelines let the HTTP plane batch up to fifty commands in one request; the RESP gateway batches consecutive pipelined reads on its own.
- Use HTTP when the caller is short-lived, polyglot or already server-side.
- Use the redis:// gateway connection string when a native Redis client is the cleanest path - same credential, no HTTP bridge code.
- Batch with the pipeline endpoint or RESP pipelining instead of paying per command.
Errors are part of the contract
A JSON API should fail in JSON. Validation, permission, quota and rate-limit failures all return a deterministic envelope with an error code and a message. A missing or expired key is a 404, not an empty string, so a cache miss and an outage never look the same.
{
"success": false,
"error": {
"code": "ERR_VALIDATION",
"message": "body must not have additional properties"
}
}Try the contract yourself.
Five databases are free. Create one, mint a scoped key and send a command.