Cache entries and keys
A cache entry has a key, a value, and an expiry time. Keys are 1 to 512 characters from letters, digits,_, :, ., -, and /.
Project permissions control access. Reading entries requires project.cache.read, and writing or deleting entries requires project.cache.write. The same key in two projects identifies two separate cache entries.
Values and expiration
Cache values are strings. Serialize structured data before you store it, and parse it after you read it. Writes acceptttl_seconds, an integer from 1 to 86,400. The default is 300 seconds. Every cache entry expires: write the entry again to keep it longer. Reads return expires_at, the RFC 3339 UTC time the entry expires.
For example, a support application can cache a serialized lookup result for a few minutes. Your application decides when cached data is stale and whether to replace or delete it.
Misses
Reading a missing or expired key isn’t an error. The response hasfound: false, and value and expires_at are null. A not_found error means the project is missing or you can’t access it.
Batches, listing, and deletion
Batch reads and writes accept up to 100 cache entries per request. A batch read returns one result per key in request order, withfound: false for misses. A batch write stores every cache entry or none.
Listing returns keys and expiry times without values, optionally filtered by a glob pattern such as session:*. Results follow scan order, so a key can appear on more than one page.
Delete one cache entry by key, or delete every cache entry matching a glob pattern. The pattern * clears the project cache. Deleting an absent key succeeds with status absent.
Cached data supports application behavior but is separate from project source, uploaded files, and execution history. The Projects API manages source and assets; the Execution API manages runs and events.