HEXPIRE to give individual hash fields a lifetime in seconds, after which those fields are removed from the hash.
Expiration here is per field, not per key: the hash itself stays alive as long as it still has fields, and the key is deleted automatically when the last surviving field expires. This makes it possible to keep short-lived and long-lived data in one hash, for example a user record whose verification code expires while the rest of the record stays.
FIELDS <numfields> introduces the list of fields and the count must match the number of names that follow. The optional condition works as it does on EXPIRE: NX only when the field has no expiration, XX only when it already has one, GT only when the new expiration is later than the current one, and LT only when it is earlier.
The reply holds one status code per field, in order: 1 when the expiration was set, 0 when the condition prevented it, 2 when the field was deleted immediately because the given lifetime was zero or negative, and -2 when the field does not exist.
Syntax
Arguments
Important points
NXcannot be combined withXX,GT, orLT, andGTandLTcannot be used together.- A field with no expiration counts as an infinite one, so
GTnever sets an expiration on such a field andLTalways does.
Response
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples
TCP examples use the TLSREDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.
Redis CLI
Redis CLI
@upstash/redis
@upstash/redis
upstash_redis
upstash_redis
ioredis
ioredis
node-redis
node-redis
redis-py
redis-py
go-redis
go-redis
jedis
jedis
redis-rs
redis-rs