Endpoint
POST /v1/memory/ttl-alerts
Request Body
{
"within": "24h",
"type": "semantic",
"renewIds": ["id1", "id2"],
"renewExpiresIn": "30d"
}
| Parameter | Type | Description |
|---|
within | string | Alert window (e.g. 1h, 24h, 7d). Default: 24h |
type | string | Filter by memory type |
renewIds | string[] | IDs to renew (max 50) |
renewExpiresIn | string | New TTL from now (required when renewIds is set) |
Response (200)
{
"expiring": [...],
"expiringCount": 5,
"within": "24h",
"renewed": [
{ "id": "id1", "success": true, "newExpiresAt": "2026-04-22T09:00:00Z" },
{ "id": "id2", "success": true, "newExpiresAt": "2026-04-22T09:00:00Z" }
],
"renewedCount": 2
}
How Renewal Works
When you renew a memory’s TTL:
- The on-chain blob expiration is extended directly — no re-upload needed
- The database
expiresAt is updated to match
This updates the expiration both on-chain and in the database, without touching the blob content.
renewExpiresIn sets the new expiration from now, not added to the current expiry.
For example, if a memory expires in 30 days and you renew with "10d", it will now expire in 10 days (not 40 days).
Workflow: Call with just within to check what’s expiring, then call again with renewIds to extend the TTL on important memories.
