[alexluong]

Destinations can carry an expiry time. Once it passes, the destination gets no more events, and it gives up its slot under the tenant's destination limit. Nothing sets the field yet: it isn't in the API, and nothing in the codebase writes it. It's groundwork for destination types that only live for a set time; with the field unset, behavior is the same as today.

An expired destination is handled like a disabled one, without being marked disabled:

1. Persistence. Destination.ExpiresAt is stored in the Redis and in-memory tenant stores; Redis also keeps it in the per-tenant summary used for event matching. Records without the field read as not expired.
2. Matching. Event matching skips expired destinations: Destination.MatchEvent (used by the in-memory store) and the Redis store's summary scan.
3. Delivery. A queued delivery to an expired destination is acked and dropped, the same as for a disabled one: no attempt, no retry.
4. Manual retry. Retrying an event to an expired destination returns 400 with destination_expired.
5. Tenant limit. When a create hits the per-tenant limit, that tenant's expired destinations are deleted and the limit is checked again. There is no background sweep, so get and list still return an expired destination until then. In Redis each delete re-checks expires_at in a script, so a destination whose expiry was moved later between the read and the delete is kept.

Other improvements:

• Redis tenant store: the 7-day TTL on soft-deleted records is one constant.

🤖 Generated with Claude Code