@linqapp/sdk 0.55.0 → 0.55.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/client.d.mts +38 -19
- package/client.d.mts.map +1 -1
- package/client.d.ts +38 -19
- package/client.d.ts.map +1 -1
- package/client.js +38 -19
- package/client.js.map +1 -1
- package/client.mjs +38 -19
- package/client.mjs.map +1 -1
- package/package.json +1 -1
- package/resources/attachments.d.mts +35 -13
- package/resources/attachments.d.mts.map +1 -1
- package/resources/attachments.d.ts +35 -13
- package/resources/attachments.d.ts.map +1 -1
- package/resources/attachments.js +31 -11
- package/resources/attachments.js.map +1 -1
- package/resources/attachments.mjs +31 -11
- package/resources/attachments.mjs.map +1 -1
- package/resources/chats/messages.d.mts +16 -12
- package/resources/chats/messages.d.mts.map +1 -1
- package/resources/chats/messages.d.ts +16 -12
- package/resources/chats/messages.d.ts.map +1 -1
- package/resources/chats/messages.js +16 -12
- package/resources/chats/messages.js.map +1 -1
- package/resources/chats/messages.mjs +16 -12
- package/resources/chats/messages.mjs.map +1 -1
- package/resources/chats/polls.d.mts +16 -12
- package/resources/chats/polls.d.mts.map +1 -1
- package/resources/chats/polls.d.ts +16 -12
- package/resources/chats/polls.d.ts.map +1 -1
- package/resources/chats/polls.js +16 -12
- package/resources/chats/polls.js.map +1 -1
- package/resources/chats/polls.mjs +16 -12
- package/resources/chats/polls.mjs.map +1 -1
- package/resources/messages/messages.d.mts +16 -12
- package/resources/messages/messages.d.mts.map +1 -1
- package/resources/messages/messages.d.ts +16 -12
- package/resources/messages/messages.d.ts.map +1 -1
- package/resources/messages/messages.js +16 -12
- package/resources/messages/messages.js.map +1 -1
- package/resources/messages/messages.mjs +16 -12
- package/resources/messages/messages.mjs.map +1 -1
- package/resources/messages/poll.d.mts +16 -12
- package/resources/messages/poll.d.mts.map +1 -1
- package/resources/messages/poll.d.ts +16 -12
- package/resources/messages/poll.d.ts.map +1 -1
- package/resources/messages/poll.js +16 -12
- package/resources/messages/poll.js.map +1 -1
- package/resources/messages/poll.mjs +16 -12
- package/resources/messages/poll.mjs.map +1 -1
- package/src/client.ts +38 -19
- package/src/resources/attachments.ts +35 -13
- package/src/resources/chats/messages.ts +16 -12
- package/src/resources/chats/polls.ts +16 -12
- package/src/resources/messages/messages.ts +16 -12
- package/src/resources/messages/poll.ts +16 -12
- package/src/version.ts +1 -1
- package/version.d.mts +1 -1
- package/version.d.ts +1 -1
- package/version.js +1 -1
- package/version.mjs +1 -1
|
@@ -31,35 +31,39 @@ const path_1 = require("../../internal/utils/path.js");
|
|
|
31
31
|
*
|
|
32
32
|
* ## Ephemeral Messages (Privacy Tier)
|
|
33
33
|
*
|
|
34
|
-
* 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
|
|
34
|
+
* 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.
|
|
35
|
+
*
|
|
36
|
+
* 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.
|
|
35
37
|
*
|
|
36
38
|
* You can request it at two scopes:
|
|
37
39
|
*
|
|
38
40
|
* | Scope | Effect |
|
|
39
41
|
* |---|---|
|
|
40
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
41
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
42
|
+
* | **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. |
|
|
43
|
+
* | **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. |
|
|
42
44
|
*
|
|
43
45
|
* **Behavioral differences vs the standard default:**
|
|
44
46
|
*
|
|
45
47
|
* | Aspect | Standard | Ephemeral |
|
|
46
48
|
* |---|---|---|
|
|
47
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
48
|
-
* | After expiry | Message stays retrievable | Message is
|
|
49
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
49
|
+
* | 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 |
|
|
50
|
+
* | 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` |
|
|
51
|
+
* | 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 |
|
|
52
|
+
* | 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 |
|
|
50
53
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
51
54
|
*
|
|
52
|
-
* **How the
|
|
55
|
+
* **How the retention window works:**
|
|
53
56
|
*
|
|
54
|
-
* - The window
|
|
55
|
-
* -
|
|
57
|
+
* - 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.
|
|
58
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
56
59
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
60
|
+
* - **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.
|
|
57
61
|
*
|
|
58
62
|
* **What you observe:**
|
|
59
63
|
*
|
|
60
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
64
|
+
* - **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.
|
|
61
65
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
62
|
-
* - **The backstop
|
|
66
|
+
* - **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.
|
|
63
67
|
* - **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.
|
|
64
68
|
*
|
|
65
69
|
* **When to choose ephemeral:**
|
|
@@ -68,7 +72,7 @@ const path_1 = require("../../internal/utils/path.js");
|
|
|
68
72
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
69
73
|
* - 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.
|
|
70
74
|
*
|
|
71
|
-
* **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
|
|
75
|
+
* **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.
|
|
72
76
|
*/
|
|
73
77
|
class Messages extends resource_1.APIResource {
|
|
74
78
|
constructor() {
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"messages.js","sourceRoot":"","sources":["../../src/resources/messages/messages.ts"],"names":[],"mappings":";AAAA,sFAAsF;;;;AAEtF,qDAAkD;AAIlD,2DAAkC;AAClC,oCAAoE;AAEpE,yDAI+B;AAC/B,uDAAsD;AAEtD,uDAAiD;AAEjD
|
|
1
|
+
{"version":3,"file":"messages.js","sourceRoot":"","sources":["../../src/resources/messages/messages.ts"],"names":[],"mappings":";AAAA,sFAAsF;;;;AAEtF,qDAAkD;AAIlD,2DAAkC;AAClC,oCAAoE;AAEpE,yDAI+B;AAC/B,uDAAsD;AAEtD,uDAAiD;AAEjD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,MAAa,QAAS,SAAQ,sBAAW;IAAzC;;QACE,SAAI,GAAiB,IAAI,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IA8OtD,CAAC;IA5OC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAoEG;IACH,MAAM,CAAC,MAA2B,EAAE,OAAwB;QAC1D,MAAM,EAAE,iBAAiB,EAAE,cAAc,EAAE,GAAG,IAAI,EAAE,GAAG,MAAM,CAAC;QAC9D,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,cAAc,EAAE;YACvC,IAAI;YACJ,GAAG,OAAO;YACV,OAAO,EAAE,IAAA,sBAAY,EAAC;gBACpB,EAAE,GAAG,CAAC,cAAc,IAAI,IAAI,CAAC,CAAC,CAAC,EAAE,iBAAiB,EAAE,cAAc,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC,EAAE;gBACnF,OAAO,EAAE,OAAO;aACjB,CAAC;SACH,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAiB,EAAE,OAAwB;QAClD,OAAO,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,EAAE,EAAE,OAAO,CAAC,CAAC;IACpE,CAAC;IAED;;;;;;;;;;;;;OAaG;IACH,MAAM,CAAC,SAAiB,EAAE,IAAyB,EAAE,OAAwB;QAC3E,OAAO,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,EAAE,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IACnF,CAAC;IAED;;;;;;;;;;;;OAYG;IACH,MAAM,CAAC,SAAiB,EAAE,OAAwB;QAChD,OAAO,IAAI,CAAC,OAAO,CAAC,MAAM,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,EAAE,EAAE;YAC1D,GAAG,OAAO;YACV,OAAO,EAAE,IAAA,sBAAY,EAAC,CAAC,EAAE,MAAM,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,OAAO,CAAC,CAAC;SAC7D,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,WAAW,CACT,SAAiB,EACjB,IAA8B,EAC9B,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,YAAY,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC5F,CAAC;IAED;;;;;;;;;;;;;;;;;OAiBG;IACH,kBAAkB,CAChB,SAAiB,EACjB,QAA4D,EAAE,EAC9D,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,UAAU,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,SAAS,EAAE,CAAA,mCAA+B,CAAA,EAAE;YACtG,KAAK;YACL,GAAG,OAAO;SACX,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAmCG;IACH,aAAa,CACX,SAAiB,EACjB,IAAgC,EAChC,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,SAAS,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IACzF,CAAC;CACF;AA/OD,4BA+OC;AA2rBD,QAAQ,CAAC,IAAI,GAAG,WAAI,CAAC"}
|
|
@@ -27,35 +27,39 @@ import { path } from "../../internal/utils/path.mjs";
|
|
|
27
27
|
*
|
|
28
28
|
* ## Ephemeral Messages (Privacy Tier)
|
|
29
29
|
*
|
|
30
|
-
* 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
|
|
30
|
+
* 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.
|
|
31
|
+
*
|
|
32
|
+
* 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.
|
|
31
33
|
*
|
|
32
34
|
* You can request it at two scopes:
|
|
33
35
|
*
|
|
34
36
|
* | Scope | Effect |
|
|
35
37
|
* |---|---|
|
|
36
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
37
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
38
|
+
* | **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. |
|
|
39
|
+
* | **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. |
|
|
38
40
|
*
|
|
39
41
|
* **Behavioral differences vs the standard default:**
|
|
40
42
|
*
|
|
41
43
|
* | Aspect | Standard | Ephemeral |
|
|
42
44
|
* |---|---|---|
|
|
43
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
44
|
-
* | After expiry | Message stays retrievable | Message is
|
|
45
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
45
|
+
* | 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 |
|
|
46
|
+
* | 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` |
|
|
47
|
+
* | 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 |
|
|
48
|
+
* | 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 |
|
|
46
49
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
47
50
|
*
|
|
48
|
-
* **How the
|
|
51
|
+
* **How the retention window works:**
|
|
49
52
|
*
|
|
50
|
-
* - The window
|
|
51
|
-
* -
|
|
53
|
+
* - 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.
|
|
54
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
52
55
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
56
|
+
* - **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.
|
|
53
57
|
*
|
|
54
58
|
* **What you observe:**
|
|
55
59
|
*
|
|
56
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
60
|
+
* - **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.
|
|
57
61
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
58
|
-
* - **The backstop
|
|
62
|
+
* - **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.
|
|
59
63
|
* - **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.
|
|
60
64
|
*
|
|
61
65
|
* **When to choose ephemeral:**
|
|
@@ -64,7 +68,7 @@ import { path } from "../../internal/utils/path.mjs";
|
|
|
64
68
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
65
69
|
* - 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.
|
|
66
70
|
*
|
|
67
|
-
* **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
|
|
71
|
+
* **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.
|
|
68
72
|
*/
|
|
69
73
|
export class Messages extends APIResource {
|
|
70
74
|
constructor() {
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"messages.mjs","sourceRoot":"","sources":["../../src/resources/messages/messages.ts"],"names":[],"mappings":"AAAA,sFAAsF;AAEtF,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAIlD,OAAO,KAAK,OAAO,mBAAe;AAClC,OAAO,EAAE,IAAI,EAAwC,mBAAe;AAEpE,OAAO,EACL,sBAAsB,GAGvB,kCAA8B;AAC/B,OAAO,EAAE,YAAY,EAAE,mCAA+B;AAEtD,OAAO,EAAE,IAAI,EAAE,sCAAkC;AAEjD
|
|
1
|
+
{"version":3,"file":"messages.mjs","sourceRoot":"","sources":["../../src/resources/messages/messages.ts"],"names":[],"mappings":"AAAA,sFAAsF;AAEtF,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAIlD,OAAO,KAAK,OAAO,mBAAe;AAClC,OAAO,EAAE,IAAI,EAAwC,mBAAe;AAEpE,OAAO,EACL,sBAAsB,GAGvB,kCAA8B;AAC/B,OAAO,EAAE,YAAY,EAAE,mCAA+B;AAEtD,OAAO,EAAE,IAAI,EAAE,sCAAkC;AAEjD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,MAAM,OAAO,QAAS,SAAQ,WAAW;IAAzC;;QACE,SAAI,GAAiB,IAAI,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IA8OtD,CAAC;IA5OC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAoEG;IACH,MAAM,CAAC,MAA2B,EAAE,OAAwB;QAC1D,MAAM,EAAE,iBAAiB,EAAE,cAAc,EAAE,GAAG,IAAI,EAAE,GAAG,MAAM,CAAC;QAC9D,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,cAAc,EAAE;YACvC,IAAI;YACJ,GAAG,OAAO;YACV,OAAO,EAAE,YAAY,CAAC;gBACpB,EAAE,GAAG,CAAC,cAAc,IAAI,IAAI,CAAC,CAAC,CAAC,EAAE,iBAAiB,EAAE,cAAc,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC,EAAE;gBACnF,OAAO,EAAE,OAAO;aACjB,CAAC;SACH,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAiB,EAAE,OAAwB;QAClD,OAAO,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,CAAA,gBAAgB,SAAS,EAAE,EAAE,OAAO,CAAC,CAAC;IACpE,CAAC;IAED;;;;;;;;;;;;;OAaG;IACH,MAAM,CAAC,SAAiB,EAAE,IAAyB,EAAE,OAAwB;QAC3E,OAAO,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAA,gBAAgB,SAAS,EAAE,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IACnF,CAAC;IAED;;;;;;;;;;;;OAYG;IACH,MAAM,CAAC,SAAiB,EAAE,OAAwB;QAChD,OAAO,IAAI,CAAC,OAAO,CAAC,MAAM,CAAC,IAAI,CAAA,gBAAgB,SAAS,EAAE,EAAE;YAC1D,GAAG,OAAO;YACV,OAAO,EAAE,YAAY,CAAC,CAAC,EAAE,MAAM,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,OAAO,CAAC,CAAC;SAC7D,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,WAAW,CACT,SAAiB,EACjB,IAA8B,EAC9B,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAA,gBAAgB,SAAS,YAAY,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC5F,CAAC;IAED;;;;;;;;;;;;;;;;;OAiBG;IACH,kBAAkB,CAChB,SAAiB,EACjB,QAA4D,EAAE,EAC9D,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,UAAU,CAAC,IAAI,CAAA,gBAAgB,SAAS,SAAS,EAAE,CAAA,sBAA+B,CAAA,EAAE;YACtG,KAAK;YACL,GAAG,OAAO;SACX,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAmCG;IACH,aAAa,CACX,SAAiB,EACjB,IAAgC,EAChC,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAA,gBAAgB,SAAS,SAAS,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IACzF,CAAC;CACF;AA2rBD,QAAQ,CAAC,IAAI,GAAG,IAAI,CAAC"}
|
|
@@ -24,35 +24,39 @@ import { RequestOptions } from "../../internal/request-options.mjs";
|
|
|
24
24
|
*
|
|
25
25
|
* ## Ephemeral Messages (Privacy Tier)
|
|
26
26
|
*
|
|
27
|
-
* 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
|
|
27
|
+
* 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.
|
|
28
|
+
*
|
|
29
|
+
* 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.
|
|
28
30
|
*
|
|
29
31
|
* You can request it at two scopes:
|
|
30
32
|
*
|
|
31
33
|
* | Scope | Effect |
|
|
32
34
|
* |---|---|
|
|
33
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
34
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
35
|
+
* | **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. |
|
|
36
|
+
* | **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. |
|
|
35
37
|
*
|
|
36
38
|
* **Behavioral differences vs the standard default:**
|
|
37
39
|
*
|
|
38
40
|
* | Aspect | Standard | Ephemeral |
|
|
39
41
|
* |---|---|---|
|
|
40
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
41
|
-
* | After expiry | Message stays retrievable | Message is
|
|
42
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
42
|
+
* | 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 |
|
|
43
|
+
* | 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` |
|
|
44
|
+
* | 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 |
|
|
45
|
+
* | 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 |
|
|
43
46
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
44
47
|
*
|
|
45
|
-
* **How the
|
|
48
|
+
* **How the retention window works:**
|
|
46
49
|
*
|
|
47
|
-
* - The window
|
|
48
|
-
* -
|
|
50
|
+
* - 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.
|
|
51
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
49
52
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
53
|
+
* - **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.
|
|
50
54
|
*
|
|
51
55
|
* **What you observe:**
|
|
52
56
|
*
|
|
53
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
57
|
+
* - **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.
|
|
54
58
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
55
|
-
* - **The backstop
|
|
59
|
+
* - **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.
|
|
56
60
|
* - **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.
|
|
57
61
|
*
|
|
58
62
|
* **When to choose ephemeral:**
|
|
@@ -61,7 +65,7 @@ import { RequestOptions } from "../../internal/request-options.mjs";
|
|
|
61
65
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
62
66
|
* - 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.
|
|
63
67
|
*
|
|
64
|
-
* **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
|
|
68
|
+
* **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.
|
|
65
69
|
*/
|
|
66
70
|
export declare class Poll extends APIResource {
|
|
67
71
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"poll.d.mts","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAClD,OAAO,KAAK,QAAQ,2BAAuB;AAC3C,OAAO,EAAE,UAAU,EAAE,mCAA+B;AACpD,OAAO,EAAE,cAAc,EAAE,2CAAuC;AAGhE
|
|
1
|
+
{"version":3,"file":"poll.d.mts","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAClD,OAAO,KAAK,QAAQ,2BAAuB;AAC3C,OAAO,EAAE,UAAU,EAAE,mCAA+B;AACpD,OAAO,EAAE,cAAc,EAAE,2CAAuC;AAGhE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,qBAAa,IAAK,SAAQ,WAAW;IACnC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAS,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,cAAc,GAAG,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;IAIxF;;;;;;;;;;;;OAYG;IACH,UAAU,CACR,SAAS,EAAE,MAAM,EACjB,IAAI,EAAE,oBAAoB,EAC1B,OAAO,CAAC,EAAE,cAAc,GACvB,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;IAIpC;;;;;;;;;;;;;;;OAeG;IACH,IAAI,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE,cAAc,EAAE,OAAO,CAAC,EAAE,cAAc,GAAG,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;CAG3G;AAED,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,KAAK,CAAC,oBAAoB,CAAC,MAAM,CAAC,CAAC;CAC7C;AAED,yBAAiB,oBAAoB,CAAC;IACpC,UAAiB,MAAM;QACrB,IAAI,EAAE,MAAM,CAAC;KACd;CACF;AAED,MAAM,WAAW,cAAc;IAC7B;;OAEG;IACH,SAAS,EAAE,KAAK,GAAG,QAAQ,CAAC;IAE5B;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,CAAC,OAAO,WAAW,IAAI,CAAC;IAC5B,OAAO,EAAE,KAAK,oBAAoB,IAAI,oBAAoB,EAAE,KAAK,cAAc,IAAI,cAAc,EAAE,CAAC;CACrG"}
|
|
@@ -24,35 +24,39 @@ import { RequestOptions } from "../../internal/request-options.js";
|
|
|
24
24
|
*
|
|
25
25
|
* ## Ephemeral Messages (Privacy Tier)
|
|
26
26
|
*
|
|
27
|
-
* 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
|
|
27
|
+
* 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.
|
|
28
|
+
*
|
|
29
|
+
* 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.
|
|
28
30
|
*
|
|
29
31
|
* You can request it at two scopes:
|
|
30
32
|
*
|
|
31
33
|
* | Scope | Effect |
|
|
32
34
|
* |---|---|
|
|
33
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
34
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
35
|
+
* | **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. |
|
|
36
|
+
* | **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. |
|
|
35
37
|
*
|
|
36
38
|
* **Behavioral differences vs the standard default:**
|
|
37
39
|
*
|
|
38
40
|
* | Aspect | Standard | Ephemeral |
|
|
39
41
|
* |---|---|---|
|
|
40
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
41
|
-
* | After expiry | Message stays retrievable | Message is
|
|
42
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
42
|
+
* | 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 |
|
|
43
|
+
* | 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` |
|
|
44
|
+
* | 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 |
|
|
45
|
+
* | 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 |
|
|
43
46
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
44
47
|
*
|
|
45
|
-
* **How the
|
|
48
|
+
* **How the retention window works:**
|
|
46
49
|
*
|
|
47
|
-
* - The window
|
|
48
|
-
* -
|
|
50
|
+
* - 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.
|
|
51
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
49
52
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
53
|
+
* - **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.
|
|
50
54
|
*
|
|
51
55
|
* **What you observe:**
|
|
52
56
|
*
|
|
53
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
57
|
+
* - **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.
|
|
54
58
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
55
|
-
* - **The backstop
|
|
59
|
+
* - **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.
|
|
56
60
|
* - **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.
|
|
57
61
|
*
|
|
58
62
|
* **When to choose ephemeral:**
|
|
@@ -61,7 +65,7 @@ import { RequestOptions } from "../../internal/request-options.js";
|
|
|
61
65
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
62
66
|
* - 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.
|
|
63
67
|
*
|
|
64
|
-
* **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
|
|
68
|
+
* **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.
|
|
65
69
|
*/
|
|
66
70
|
export declare class Poll extends APIResource {
|
|
67
71
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"poll.d.ts","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,WAAW,EAAE,+BAA4B;AAClD,OAAO,KAAK,QAAQ,0BAAuB;AAC3C,OAAO,EAAE,UAAU,EAAE,kCAA+B;AACpD,OAAO,EAAE,cAAc,EAAE,0CAAuC;AAGhE
|
|
1
|
+
{"version":3,"file":"poll.d.ts","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,WAAW,EAAE,+BAA4B;AAClD,OAAO,KAAK,QAAQ,0BAAuB;AAC3C,OAAO,EAAE,UAAU,EAAE,kCAA+B;AACpD,OAAO,EAAE,cAAc,EAAE,0CAAuC;AAGhE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,qBAAa,IAAK,SAAQ,WAAW;IACnC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAS,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,cAAc,GAAG,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;IAIxF;;;;;;;;;;;;OAYG;IACH,UAAU,CACR,SAAS,EAAE,MAAM,EACjB,IAAI,EAAE,oBAAoB,EAC1B,OAAO,CAAC,EAAE,cAAc,GACvB,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;IAIpC;;;;;;;;;;;;;;;OAeG;IACH,IAAI,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,EAAE,cAAc,EAAE,OAAO,CAAC,EAAE,cAAc,GAAG,UAAU,CAAC,QAAQ,CAAC,YAAY,CAAC;CAG3G;AAED,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,KAAK,CAAC,oBAAoB,CAAC,MAAM,CAAC,CAAC;CAC7C;AAED,yBAAiB,oBAAoB,CAAC;IACpC,UAAiB,MAAM;QACrB,IAAI,EAAE,MAAM,CAAC;KACd;CACF;AAED,MAAM,WAAW,cAAc;IAC7B;;OAEG;IACH,SAAS,EAAE,KAAK,GAAG,QAAQ,CAAC;IAE5B;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,CAAC,OAAO,WAAW,IAAI,CAAC;IAC5B,OAAO,EAAE,KAAK,oBAAoB,IAAI,oBAAoB,EAAE,KAAK,cAAc,IAAI,cAAc,EAAE,CAAC;CACrG"}
|
|
@@ -26,35 +26,39 @@ const path_1 = require("../../internal/utils/path.js");
|
|
|
26
26
|
*
|
|
27
27
|
* ## Ephemeral Messages (Privacy Tier)
|
|
28
28
|
*
|
|
29
|
-
* 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
|
|
29
|
+
* 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.
|
|
30
|
+
*
|
|
31
|
+
* 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.
|
|
30
32
|
*
|
|
31
33
|
* You can request it at two scopes:
|
|
32
34
|
*
|
|
33
35
|
* | Scope | Effect |
|
|
34
36
|
* |---|---|
|
|
35
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
36
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
37
|
+
* | **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. |
|
|
38
|
+
* | **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. |
|
|
37
39
|
*
|
|
38
40
|
* **Behavioral differences vs the standard default:**
|
|
39
41
|
*
|
|
40
42
|
* | Aspect | Standard | Ephemeral |
|
|
41
43
|
* |---|---|---|
|
|
42
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
43
|
-
* | After expiry | Message stays retrievable | Message is
|
|
44
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
44
|
+
* | 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 |
|
|
45
|
+
* | 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` |
|
|
46
|
+
* | 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 |
|
|
47
|
+
* | 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 |
|
|
45
48
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
46
49
|
*
|
|
47
|
-
* **How the
|
|
50
|
+
* **How the retention window works:**
|
|
48
51
|
*
|
|
49
|
-
* - The window
|
|
50
|
-
* -
|
|
52
|
+
* - 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.
|
|
53
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
51
54
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
55
|
+
* - **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.
|
|
52
56
|
*
|
|
53
57
|
* **What you observe:**
|
|
54
58
|
*
|
|
55
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
59
|
+
* - **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.
|
|
56
60
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
57
|
-
* - **The backstop
|
|
61
|
+
* - **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.
|
|
58
62
|
* - **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.
|
|
59
63
|
*
|
|
60
64
|
* **When to choose ephemeral:**
|
|
@@ -63,7 +67,7 @@ const path_1 = require("../../internal/utils/path.js");
|
|
|
63
67
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
64
68
|
* - 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.
|
|
65
69
|
*
|
|
66
|
-
* **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
|
|
70
|
+
* **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.
|
|
67
71
|
*/
|
|
68
72
|
class Poll extends resource_1.APIResource {
|
|
69
73
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"poll.js","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":";AAAA,sFAAsF;;;AAEtF,qDAAkD;AAIlD,uDAAiD;AAEjD
|
|
1
|
+
{"version":3,"file":"poll.js","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":";AAAA,sFAAsF;;;AAEtF,qDAAkD;AAIlD,uDAAiD;AAEjD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,MAAa,IAAK,SAAQ,sBAAW;IACnC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAiB,EAAE,OAAwB;QAClD,OAAO,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,OAAO,EAAE,OAAO,CAAC,CAAC;IACzE,CAAC;IAED;;;;;;;;;;;;OAYG;IACH,UAAU,CACR,SAAiB,EACjB,IAA0B,EAC1B,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,eAAe,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC/F,CAAC;IAED;;;;;;;;;;;;;;;OAeG;IACH,IAAI,CAAC,SAAiB,EAAE,IAAoB,EAAE,OAAwB;QACpE,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAA,WAAI,EAAA,gBAAgB,SAAS,aAAa,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC7F,CAAC;CACF;AAxDD,oBAwDC"}
|
|
@@ -23,35 +23,39 @@ import { path } from "../../internal/utils/path.mjs";
|
|
|
23
23
|
*
|
|
24
24
|
* ## Ephemeral Messages (Privacy Tier)
|
|
25
25
|
*
|
|
26
|
-
* 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
|
|
26
|
+
* 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.
|
|
27
|
+
*
|
|
28
|
+
* 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.
|
|
27
29
|
*
|
|
28
30
|
* You can request it at two scopes:
|
|
29
31
|
*
|
|
30
32
|
* | Scope | Effect |
|
|
31
33
|
* |---|---|
|
|
32
|
-
* | **Partner-wide** | Every outbound and inbound message on every phone number under your account
|
|
33
|
-
* | **Per phone number** | Only the specified phone numbers have
|
|
34
|
+
* | **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. |
|
|
35
|
+
* | **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. |
|
|
34
36
|
*
|
|
35
37
|
* **Behavioral differences vs the standard default:**
|
|
36
38
|
*
|
|
37
39
|
* | Aspect | Standard | Ephemeral |
|
|
38
40
|
* |---|---|---|
|
|
39
|
-
* | Retention | Retained per the standard message-retention policy | **Hard backstop: 24 hours
|
|
40
|
-
* | After expiry | Message stays retrievable | Message is
|
|
41
|
-
* | Content on expiry | N/A | Text, formatting, and attachment references are
|
|
41
|
+
* | 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 |
|
|
42
|
+
* | 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` |
|
|
43
|
+
* | 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 |
|
|
44
|
+
* | 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 |
|
|
42
45
|
* | Cross-partner isolation | Enforced | Enforced |
|
|
43
46
|
*
|
|
44
|
-
* **How the
|
|
47
|
+
* **How the retention window works:**
|
|
45
48
|
*
|
|
46
|
-
* - The window
|
|
47
|
-
* -
|
|
49
|
+
* - 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.
|
|
50
|
+
* - Attachment media follows its own storage backstop rather than the message window — see the Attachments row above.
|
|
48
51
|
* - Expiry is delivery-independent — the clock starts when the message is created, not when it is delivered or read.
|
|
52
|
+
* - **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.
|
|
49
53
|
*
|
|
50
54
|
* **What you observe:**
|
|
51
55
|
*
|
|
52
|
-
* - **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time.
|
|
56
|
+
* - **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.
|
|
53
57
|
* - **No deletion webhook is sent.** There is no `message.deleted` event — a message simply stops being retrievable once its window passes.
|
|
54
|
-
* - **The backstop
|
|
58
|
+
* - **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.
|
|
55
59
|
* - **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.
|
|
56
60
|
*
|
|
57
61
|
* **When to choose ephemeral:**
|
|
@@ -60,7 +64,7 @@ import { path } from "../../internal/utils/path.mjs";
|
|
|
60
64
|
* - The conversation is high-sensitivity (PHI, financial, identity verification) and you do not want it sitting in storage long-term.
|
|
61
65
|
* - 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.
|
|
62
66
|
*
|
|
63
|
-
* **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
|
|
67
|
+
* **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.
|
|
64
68
|
*/
|
|
65
69
|
export class Poll extends APIResource {
|
|
66
70
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"poll.mjs","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAAA,sFAAsF;AAEtF,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAIlD,OAAO,EAAE,IAAI,EAAE,sCAAkC;AAEjD
|
|
1
|
+
{"version":3,"file":"poll.mjs","sourceRoot":"","sources":["../../src/resources/messages/poll.ts"],"names":[],"mappings":"AAAA,sFAAsF;AAEtF,OAAO,EAAE,WAAW,EAAE,gCAA4B;AAIlD,OAAO,EAAE,IAAI,EAAE,sCAAkC;AAEjD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,MAAM,OAAO,IAAK,SAAQ,WAAW;IACnC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,SAAiB,EAAE,OAAwB;QAClD,OAAO,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,CAAA,gBAAgB,SAAS,OAAO,EAAE,OAAO,CAAC,CAAC;IACzE,CAAC;IAED;;;;;;;;;;;;OAYG;IACH,UAAU,CACR,SAAiB,EACjB,IAA0B,EAC1B,OAAwB;QAExB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAA,gBAAgB,SAAS,eAAe,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC/F,CAAC;IAED;;;;;;;;;;;;;;;OAeG;IACH,IAAI,CAAC,SAAiB,EAAE,IAAoB,EAAE,OAAwB;QACpE,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAA,gBAAgB,SAAS,aAAa,EAAE,EAAE,IAAI,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC;IAC7F,CAAC;CACF"}
|