linq-python 0.41.0__py3-none-any.whl → 0.41.2__py3-none-any.whl

linq/_client.py

@@ -186,35 +186,39 @@ class LinqAPIV3(SyncAPIClient):
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -223,7 +227,7 @@ class LinqAPIV3(SyncAPIClient):
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import MessagesResource
 
@@ -257,13 +261,28 @@ class LinqAPIV3(SyncAPIClient):
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -314,7 +333,7 @@ class LinqAPIV3(SyncAPIClient):
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -333,7 +352,7 @@ class LinqAPIV3(SyncAPIClient):
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -393,9 +412,9 @@ class LinqAPIV3(SyncAPIClient):
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -407,7 +426,7 @@ class LinqAPIV3(SyncAPIClient):
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """
@@ -1302,35 +1321,39 @@ class AsyncLinqAPIV3(AsyncAPIClient):
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -1339,7 +1362,7 @@ class AsyncLinqAPIV3(AsyncAPIClient):
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import AsyncMessagesResource
 
@@ -1373,13 +1396,28 @@ class AsyncLinqAPIV3(AsyncAPIClient):
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -1430,7 +1468,7 @@ class AsyncLinqAPIV3(AsyncAPIClient):
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -1449,7 +1487,7 @@ class AsyncLinqAPIV3(AsyncAPIClient):
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -1509,9 +1547,9 @@ class AsyncLinqAPIV3(AsyncAPIClient):
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -1523,7 +1561,7 @@ class AsyncLinqAPIV3(AsyncAPIClient):
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """
@@ -2352,35 +2390,39 @@ class LinqAPIV3WithRawResponse:
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -2389,7 +2431,7 @@ class LinqAPIV3WithRawResponse:
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import MessagesResourceWithRawResponse
 
@@ -2423,13 +2465,28 @@ class LinqAPIV3WithRawResponse:
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -2480,7 +2537,7 @@ class LinqAPIV3WithRawResponse:
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -2499,7 +2556,7 @@ class LinqAPIV3WithRawResponse:
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -2559,9 +2616,9 @@ class LinqAPIV3WithRawResponse:
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -2573,7 +2630,7 @@ class LinqAPIV3WithRawResponse:
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """
@@ -3274,35 +3331,39 @@ class AsyncLinqAPIV3WithRawResponse:
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -3311,7 +3372,7 @@ class AsyncLinqAPIV3WithRawResponse:
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import AsyncMessagesResourceWithRawResponse
 
@@ -3345,13 +3406,28 @@ class AsyncLinqAPIV3WithRawResponse:
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -3402,7 +3478,7 @@ class AsyncLinqAPIV3WithRawResponse:
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -3421,7 +3497,7 @@ class AsyncLinqAPIV3WithRawResponse:
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -3481,9 +3557,9 @@ class AsyncLinqAPIV3WithRawResponse:
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -3495,7 +3571,7 @@ class AsyncLinqAPIV3WithRawResponse:
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """
@@ -4196,35 +4272,39 @@ class LinqAPIV3WithStreamedResponse:
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -4233,7 +4313,7 @@ class LinqAPIV3WithStreamedResponse:
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import MessagesResourceWithStreamingResponse
 
@@ -4267,13 +4347,28 @@ class LinqAPIV3WithStreamedResponse:
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -4324,7 +4419,7 @@ class LinqAPIV3WithStreamedResponse:
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -4343,7 +4438,7 @@ class LinqAPIV3WithStreamedResponse:
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -4403,9 +4498,9 @@ class LinqAPIV3WithStreamedResponse:
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -4417,7 +4512,7 @@ class LinqAPIV3WithStreamedResponse:
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """
@@ -5118,35 +5213,39 @@ class AsyncLinqAPIV3WithStreamedResponse:
 
         ## Ephemeral Messages (Privacy Tier)
 
-        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is automatically given a fixed **24-hour retention window** — after that window the platform permanently deletes the message from Linq storage. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+        For regulated or sensitive conversations, opt in to the **ephemeral messages** tier by contacting your Linq support contact. When enabled, every message on the covered phone numbers is given a **retention window configured for your account**. After that window, the message's text, formatting, and attachment references are no longer retrievable through the API — see the Attachments row below for how the attachment media itself is handled. Metadata about the message is retained: message identifiers, timestamps, phone numbers, and delivery state. Metadata retention is not bounded by this window. Bounded operational copies, such as backups and delivery queues, expire on their own separate schedules. There is no per-message flag; ephemerality is applied automatically based on your configuration.
+
+        The window can be set anywhere from **60 minutes to 24 hours**, and defaults to **24 hours**. Ask your Linq support contact to configure a shorter window; it cannot be changed through the API.
 
         You can request it at two scopes:
 
         | Scope | Effect |
         |---|---|
-        | **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
-        | **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |
+        | **Partner-wide** | Every outbound and inbound message on every phone number under your account has its content removed from the API surface after your configured window. Metadata is retained. |
+        | **Per phone number** | Only the specified phone numbers have message content removed from the API surface this way. The rest follow the standard message-retention policy. |
 
         **Behavioral differences vs the standard default:**
 
         | Aspect | Standard | Ephemeral |
         |---|---|---|
-        | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours** from when the message is created |
-        | After expiry | Message stays retrievable | Message is permanently deleted — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
-        | Content on expiry | N/A | Text, formatting, and attachment references are scrubbed; the message is gone, not blanked out |
+        | Retention | Retained per the standard message-retention policy | **Hard backstop: your configured window** (60 minutes – 24 hours, default 24 hours) from when the message is created |
+        | After expiry | Message stays retrievable | Message content is no longer retrievable — `GET /v3/messages/{messageId}` returns `404` and it no longer appears in `GET /v3/chats/{chatId}/messages` |
+        | Content on expiry | N/A | Text, formatting, and attachment references are removed from the API surface, not blanked out in place. Metadata (identifiers, timestamps, phone numbers, delivery state) is retained; its retention is not bounded by this window |
+        | Attachments | Retained | Media sent on the **ephemeral attachments tier** is removed on its own storage backstop — within roughly 24–48 hours of upload — independently of the message window, so it can outlast a window shorter than a day. Attachments on the persistent tier (including pre-uploads via `POST /v3/attachments`) are kept until you `DELETE` them |
         | Cross-partner isolation | Enforced | Enforced |
 
-        **How the 24-hour window works:**
+        **How the retention window works:**
 
-        - The window is fixed at **24 hours from message creation** (`created_at`) and cannot be configured per message.
-        - It mirrors the ephemeral *attachments* 1-day backstop, so a message and any media it carries expire together.
+        - The window runs from **message creation** (`created_at`). It is configured for your account (60 minutes – 24 hours, default 24 hours) and cannot be set per message.
+        - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
         - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
+        - **Deletion happens shortly *after* the window, not exactly at it.** A background sweep runs every ~5 minutes, so a message typically stops being retrievable within about 5 minutes of its expiry, and longer while a backlog is being worked through. Treat the window as the guaranteed *minimum* retention, never as an exact deletion time or an upper bound.
 
         **What you observe:**
 
-        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute `created_at + 24h` yourself.
+        - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time, and they do not report your configured window either — so if you are on a window shorter than 24 hours you cannot derive a message's expiry from the API today. Track the window you agreed with your Linq support contact and compute `created_at + window` yourself.
         - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
-        - **The backstop governs Linq storage.** API retrievability (the `404` behavior above) and CDN media expire at the 24-hour mark. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
+        - **The attachment backstop is separate from the message window.** API retrievability (the `404` behavior above) ends at your configured window. Ephemeral-tier media objects are removed on their own storage backstop — within roughly 24–48 hours of upload — which is independent of the message window and can outlast a window shorter than a day. Removal of the corresponding entries from the sending device happens asynchronously and can complete after the backstop.
         - **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual `message.sent` / `message.received` and status webhooks exactly like standard messages. Only retention changes.
 
         **When to choose ephemeral:**
@@ -5155,7 +5254,7 @@ class AsyncLinqAPIV3WithStreamedResponse:
         - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
         - Your application is the system of record — you capture what you need from the delivery webhook in real time and do not rely on reading message history back from Linq later.
 
-        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message after 24 hours, persist anything you need to keep from the webhook payload at the time it is delivered.
+        **Important:** ephemeral applies in *both directions* — messages you send **and** messages received by the phone numbers in that scope. Because Linq can no longer return the message once its window passes, persist anything you need to keep from the webhook payload at the time it is delivered.
         """
         from .resources.messages import AsyncMessagesResourceWithStreamingResponse
 
@@ -5189,13 +5288,28 @@ class AsyncLinqAPIV3WithStreamedResponse:
         - **Reduce message send latency** — the file is already stored, so sending is faster
 
         **How it works:**
-        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a permanent `attachment_id`
+        1. `POST /v3/attachments` with file metadata → returns a presigned `upload_url` (valid for **15 minutes**) and a reusable `attachment_id`
         2. PUT the raw file bytes to the `upload_url` with the `required_headers` (no JSON or multipart — just the binary content)
-        3. Reference the `attachment_id` in your media part when sending messages (no expiration)
+        3. Reference the `attachment_id` in your media part when sending messages (stays valid unless deleted — see [Attachment Lifetime](#attachment-lifetime))
 
         **Key difference:** When you provide an external `url`, we download and process the file on every send.
         When you use a pre-uploaded `attachment_id`, the file is already stored — so repeated sends skip the download step entirely.
 
+        ## Attachment Lifetime
+
+        An `attachment_id` and its CDN URL stay valid until the file is deleted. Three things delete it:
+
+        | Trigger | Applies to |
+        |---|---|
+        | `DELETE /v3/attachments/{attachmentId}` | Any attachment you own |
+        | Ephemeral **attachments** tier (24–48h storage backstop) | Attachments on ephemeral-tier partners or phone numbers |
+        | Ephemeral **messages** tier | Does **not** remove attachment bytes on its own: ephemeral-tier objects are removed by the 24–48h storage backstop above, and persistent-tier attachments are kept until you `DELETE` them explicitly. |
+
+        Deletion is not reversible, and there is no `attachment.deleted` webhook. On either
+        ephemeral tier, download anything you need to keep when you receive it rather than
+        re-fetching later, and do not assume a pre-uploaded `attachment_id` can be reused
+        indefinitely.
+
         ## Domain Allowlisting
 
         Attachment URLs in API responses are served from `cdn.linqapp.com`. This includes:
@@ -5246,7 +5360,7 @@ class AsyncLinqAPIV3WithStreamedResponse:
 
         | Tier | URL pattern | TTL |
         |---|---|---|
-        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived |
+        | Persistent (default) | `https://cdn.linqapp.com/attachments/partners/{partner_id}/{attachment_id}/{filename}` | Long-lived — the URL itself does not expire, but see [Attachment Lifetime](#attachment-lifetime) |
         | Ephemeral | Pre-signed URL pointing at the ephemeral prefix on `cdn.linqapp.com` | 15 minutes per signed URL — re-fetch via the API for a fresh URL |
 
         Inbound media you receive over webhooks uses the same layout your outbound sends produce, so the URL you store and the URL you build look identical — no special casing in your client.
@@ -5265,7 +5379,7 @@ class AsyncLinqAPIV3WithStreamedResponse:
         | Aspect | Persistent | Ephemeral |
         |---|---|---|
         | Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
-        | Retention floor | Indefinite (until you call `DELETE`) | **Hard backstop: 1 day** — even without an explicit `DELETE`, the platform removes the underlying bytes after 24 hours |
+        | Retention floor | Until you call `DELETE` | **Hard backstop: 24–48h** — even without an explicit `DELETE`, the platform removes the underlying bytes within roughly 24–48 hours of upload |
         | URL re-fetch | Not required | Fetch via `GET /v3/attachments/{attachmentId}` for a fresh signed URL after TTL expiry |
         | Cross-partner isolation | Enforced | Enforced |
 
@@ -5325,9 +5439,9 @@ class AsyncLinqAPIV3WithStreamedResponse:
 
         | Data | Persistent tier | Ephemeral tier |
         |---|---|---|
-        | Attachment bytes | Retained until you `DELETE` | **Auto-removed after 1 day**, also removable via `DELETE` |
+        | Attachment bytes | Retained until you `DELETE` | **Auto-removed within roughly 24–48 hours** of upload, independently of any message window. Also removable via `DELETE` |
         | Attachment metadata (id, filename, mime type, size) | Retained until you `DELETE` | Removed alongside the bytes |
-        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message and its parts are deleted 24 hours after creation |
+        | Message body & parts | Retained per message-retention policy | Retained per message-retention policy — unless the line also has **ephemeral messages** enabled (see the Messages page), in which case the message's text, formatting, and attachment references are no longer retrievable through the API after that account's configured retention window (60 minutes – 24 hours, default 24 hours) from creation. Metadata is retained; see the Messages page for details |
         | Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |
 
         **In transit:** TLS 1.2+ everywhere. **At rest:** AES-256 (server-side encryption).
@@ -5339,7 +5453,7 @@ class AsyncLinqAPIV3WithStreamedResponse:
         - Allowlist exactly one outbound domain: `cdn.linqapp.com`.
         - Decide whether you need ephemeral attachments (high-sensitivity content) — request enablement through your Linq support contact.
         - Implement `DELETE /v3/attachments/{attachmentId}` calls in your deletion workflow.
-        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges after 1 day.
+        - Persist any attachments your application needs long-term — Linq is the authoritative source until you delete, but the ephemeral tier auto-purges within roughly 24–48 hours of upload.
         - For audit: every deletion is logged on Linq's side. Surface a confirmation in your application UI based on the `204` response.
         - For end-user "right to delete" requests: enumerate attachment ids and `DELETE` each. The platform does not provide a partner-wide wipe endpoint — deletion is per-attachment by design.
         """