@sentdm/sentdm 0.39.0 → 0.40.0

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.
Files changed (42) hide show
  1. package/CHANGELOG.md +8 -0
  2. package/client.d.mts +2 -0
  3. package/client.d.mts.map +1 -1
  4. package/client.d.ts +2 -0
  5. package/client.d.ts.map +1 -1
  6. package/client.js +2 -0
  7. package/client.js.map +1 -1
  8. package/client.mjs +2 -0
  9. package/client.mjs.map +1 -1
  10. package/package.json +1 -1
  11. package/resources/conversations.d.mts +71 -3
  12. package/resources/conversations.d.mts.map +1 -1
  13. package/resources/conversations.d.ts +71 -3
  14. package/resources/conversations.d.ts.map +1 -1
  15. package/resources/messages.d.mts +171 -14
  16. package/resources/messages.d.mts.map +1 -1
  17. package/resources/messages.d.ts +171 -14
  18. package/resources/messages.d.ts.map +1 -1
  19. package/resources/messages.js +21 -3
  20. package/resources/messages.js.map +1 -1
  21. package/resources/messages.mjs +21 -3
  22. package/resources/messages.mjs.map +1 -1
  23. package/resources/templates.d.mts +123 -1
  24. package/resources/templates.d.mts.map +1 -1
  25. package/resources/templates.d.ts +123 -1
  26. package/resources/templates.d.ts.map +1 -1
  27. package/resources/templates.js.map +1 -1
  28. package/resources/templates.mjs.map +1 -1
  29. package/resources/webhooks.d.mts +404 -24
  30. package/resources/webhooks.d.mts.map +1 -1
  31. package/resources/webhooks.d.ts +404 -24
  32. package/resources/webhooks.d.ts.map +1 -1
  33. package/src/client.ts +2 -0
  34. package/src/resources/conversations.ts +78 -3
  35. package/src/resources/messages.ts +182 -14
  36. package/src/resources/templates.ts +135 -1
  37. package/src/resources/webhooks.ts +441 -25
  38. package/src/version.ts +1 -1
  39. package/version.d.mts +1 -1
  40. package/version.d.ts +1 -1
  41. package/version.js +1 -1
  42. package/version.mjs +1 -1
@@ -426,7 +426,9 @@ export interface ChannelEventPayload {
426
426
  * The account whose market this is, named as on every other family. When an
427
427
  * organization receives an event for one of its sender profiles this is the
428
428
  * profile, so a reseller compares it with its own id and anything different is one
429
- * of its profiles.
429
+ * of its profiles. Matches customer_id on GET /v3/channels and the sender
430
+ * profile's id. Together with channel, country, and number_type, it identifies the
431
+ * market.
430
432
  */
431
433
  account_id?: string;
432
434
 
@@ -437,6 +439,27 @@ export interface ChannelEventPayload {
437
439
  */
438
440
  channel?: string;
439
441
 
442
+ /**
443
+ * What a market has been given: the identity it registers under, its programme,
444
+ * and any documents attached.
445
+ *
446
+ * What it does not carry is what the market asks for. That is the subject of GET
447
+ * /v3/compliance/requirements, and it is the same answer for every caller — a
448
+ * description of what a compliance regime wants, not a record of one customer's
449
+ * progress through it. It was reported here as well for a while, which put the
450
+ * same array in six response shapes and left a caller deciding which of two
451
+ * sources to believe.
452
+ *
453
+ * Present on a list read for markets that register (carrying brand and campaign),
454
+ * but with documents absent — documents are not fetched for a list, because a
455
+ * catalog lookup and a document read per market would multiply across a page.
456
+ * Absent documents is distinct from an empty list: absent says they were not
457
+ * fetched; empty says the market has been given none. The parent object is null
458
+ * only when the market registers with nobody and compliance was not computed —
459
+ * nothing to show at all.
460
+ */
461
+ compliance?: ChannelEventPayload.Compliance | null;
462
+
440
463
  /**
441
464
  * The kind of sender the market uses, for example TEN_DLC, LOCAL, or ALPHANUMERIC.
442
465
  * Omitted when the subject has no sender type of its own.
@@ -487,6 +510,95 @@ export interface ChannelEventPayload {
487
510
  updated_at?: string;
488
511
  }
489
512
 
513
+ export namespace ChannelEventPayload {
514
+ /**
515
+ * What a market has been given: the identity it registers under, its programme,
516
+ * and any documents attached.
517
+ *
518
+ * What it does not carry is what the market asks for. That is the subject of GET
519
+ * /v3/compliance/requirements, and it is the same answer for every caller — a
520
+ * description of what a compliance regime wants, not a record of one customer's
521
+ * progress through it. It was reported here as well for a while, which put the
522
+ * same array in six response shapes and left a caller deciding which of two
523
+ * sources to believe.
524
+ *
525
+ * Present on a list read for markets that register (carrying brand and campaign),
526
+ * but with documents absent — documents are not fetched for a list, because a
527
+ * catalog lookup and a document read per market would multiply across a page.
528
+ * Absent documents is distinct from an empty list: absent says they were not
529
+ * fetched; empty says the market has been given none. The parent object is null
530
+ * only when the market registers with nobody and compliance was not computed —
531
+ * nothing to show at all.
532
+ */
533
+ export interface Compliance {
534
+ /**
535
+ * The identity this market registers under, with inherit saying whose it is.
536
+ *
537
+ * Reported here rather than on the profile because it belongs to the registration
538
+ * this market files, and only one market files one. It was a top-level block for a
539
+ * while, which put a per-registration value beside a list of markets and left a
540
+ * caller to work out which market it belonged to.
541
+ *
542
+ * Absent for a market that registers with nobody — such a market asks for no
543
+ * identity, so there is none to report. Absent and null mean different things:
544
+ * absent says this market does not ask, null would say it asks and nothing was
545
+ * supplied.
546
+ *
547
+ * Untyped, like the request side, because its members are declared by the market's
548
+ * own schema rather than by a C# class. A typed pair here would be a second
549
+ * definition of what a market wants, free to drift from the one that validates.
550
+ */
551
+ brand?: { [key: string]: unknown } | null;
552
+
553
+ /**
554
+ * The programme this market registers, with inherit saying whose it is.
555
+ *
556
+ * One, not a list. TcrCampaigns permits several and an account built on the admin
557
+ * side may hold them, but this surface offers one — which is what lets the
558
+ * market's PATCH be an upsert rather than a collection with an addressable create
559
+ * behind it. An account holding several is reported as its first and refused on
560
+ * write, rather than half-edited.
561
+ *
562
+ * Carries no id. Nothing addresses a campaign, and an undeclared key would be
563
+ * refused if the caller sent this object back — which it is meant to be able to
564
+ * do.
565
+ */
566
+ campaign?: { [key: string]: unknown } | null;
567
+
568
+ /**
569
+ * What has been supplied for this market.
570
+ *
571
+ * Files, not values — the declared halves above carry the values. A document
572
+ * cannot be a JSON value, so it is sent as multipart on the channel call and
573
+ * reported here as a reference.
574
+ *
575
+ * Absent on a list read, which fetches identity but does not compute compliance
576
+ * documents per market. Absent and empty mean different things: absent says the
577
+ * documents were not fetched; empty says the market has been given none.
578
+ */
579
+ documents?: Array<Compliance.Document> | null;
580
+ }
581
+
582
+ export namespace Compliance {
583
+ /**
584
+ * A document a market asked for and has been given.
585
+ */
586
+ export interface Document {
587
+ /**
588
+ * Identifier of the upload, for fetching it back through the documents endpoints.
589
+ */
590
+ document_id?: string | null;
591
+
592
+ file_name?: string | null;
593
+
594
+ /**
595
+ * The catalog's name for this document, matching the requirement it satisfies.
596
+ */
597
+ key?: string;
598
+ }
599
+ }
600
+ }
601
+
490
602
  /**
491
603
  * The envelope Sent POSTs to a subscribed webhook endpoint. Every event shares
492
604
  * this shape and varies only in Payload.
@@ -506,17 +618,25 @@ export interface ContactEvent {
506
618
  field?: string;
507
619
 
508
620
  /**
509
- * Body of a contact.opt_in, contact.opt_out or contact.help event. Delivered when
510
- * a contact signals a consent change or asks for help.
621
+ * Body of a contact.opt_in, contact.opt_out, contact.help or
622
+ * contact.custom_keyword event. Delivered when a contact signals a consent change,
623
+ * asks for help, or sends one of your own auto-reply keywords.
511
624
  *
512
625
  * These events state the signal outright, so you do not have to recognise keywords
513
626
  * in the text of a message.received event. They also cover cases that produce no
514
627
  * inbound message at all, such as a network handling an opt-out on your behalf.
515
628
  *
516
- * Fields are ordered identity → resulting state → provenance → join key. Nothing
517
- * here restates the envelope: which of the three signals occurred is the
518
- * envelope's event, and when it was emitted is its timestamp. Retries carry the
519
- * same X-Webhook-Event-ID header, which is what to deduplicate on.
629
+ * Two of the four change consent and two do not: contact.help and
630
+ * contact.custom_keyword report the state the contact already had. Read opt_out
631
+ * for the state and the envelope's event for what happened, rather than inferring
632
+ * one from the other.
633
+ *
634
+ * Fields are ordered identity → resulting state → provenance → join keys. The two
635
+ * parties are from and to. Note that the message family has not moved to those
636
+ * names yet — message.received still calls the same two parties inbound_number and
637
+ * outbound_number. Nothing here restates the envelope: which signal occurred is
638
+ * the envelope's event, and when it was emitted is its timestamp. Retries carry
639
+ * the same X-Webhook-Event-ID header, which is what to deduplicate on.
520
640
  */
521
641
  payload?: ContactEventPayload | null;
522
642
 
@@ -534,23 +654,32 @@ export interface ContactEvent {
534
654
  }
535
655
 
536
656
  /**
537
- * Body of a contact.opt_in, contact.opt_out or contact.help event. Delivered when
538
- * a contact signals a consent change or asks for help.
657
+ * Body of a contact.opt_in, contact.opt_out, contact.help or
658
+ * contact.custom_keyword event. Delivered when a contact signals a consent change,
659
+ * asks for help, or sends one of your own auto-reply keywords.
539
660
  *
540
661
  * These events state the signal outright, so you do not have to recognise keywords
541
662
  * in the text of a message.received event. They also cover cases that produce no
542
663
  * inbound message at all, such as a network handling an opt-out on your behalf.
543
664
  *
544
- * Fields are ordered identity → resulting state → provenance → join key. Nothing
545
- * here restates the envelope: which of the three signals occurred is the
546
- * envelope's event, and when it was emitted is its timestamp. Retries carry the
547
- * same X-Webhook-Event-ID header, which is what to deduplicate on.
665
+ * Two of the four change consent and two do not: contact.help and
666
+ * contact.custom_keyword report the state the contact already had. Read opt_out
667
+ * for the state and the envelope's event for what happened, rather than inferring
668
+ * one from the other.
669
+ *
670
+ * Fields are ordered identity → resulting state → provenance → join keys. The two
671
+ * parties are from and to. Note that the message family has not moved to those
672
+ * names yet — message.received still calls the same two parties inbound_number and
673
+ * outbound_number. Nothing here restates the envelope: which signal occurred is
674
+ * the envelope's event, and when it was emitted is its timestamp. Retries carry
675
+ * the same X-Webhook-Event-ID header, which is what to deduplicate on.
548
676
  */
549
677
  export interface ContactEventPayload {
550
678
  /**
551
679
  * Whether the contact is opted out after this signal — the state to write to your
552
- * own record. Same meaning as opt_out on the contact resource. On contact.help
553
- * this reports the contact's existing state, which help does not change.
680
+ * own record. Same meaning as opt_out on the contact resource. On contact.help and
681
+ * contact.custom_keyword this reports the contact's existing state, which neither
682
+ * changes.
554
683
  *
555
684
  * Two signals from the same contact can arrive out of order, because each one is
556
685
  * queued on its own rather than against the contact. Compare the envelope's
@@ -574,6 +703,17 @@ export interface ContactEventPayload {
574
703
  */
575
704
  account_id?: string;
576
705
 
706
+ /**
707
+ * The RCS agent the signal reached, when it reached one.
708
+ *
709
+ * Omitted entirely on channels that have no agent, rather than sent as null — an
710
+ * SMS or WhatsApp payload does not carry this key at all. On RCS it is the
711
+ * counterpart to To: a contact reaches an agent rather than a number, so exactly
712
+ * one of the two is populated and never both. If you run more than one agent, this
713
+ * is what tells you which of them the contact acted on.
714
+ */
715
+ agent_id?: string | null;
716
+
577
717
  /**
578
718
  * The channel the signal arrived on, for example sms or whatsapp.
579
719
  */
@@ -581,11 +721,18 @@ export interface ContactEventPayload {
581
721
 
582
722
  /**
583
723
  * The contact who raised the signal. Always populated, including for contact.help
584
- * from a number you have not messaged before — the contact is created if it does
585
- * not exist yet, so this identifier is always resolvable against the contacts API.
724
+ * or contact.custom_keyword from a number you have not messaged before — the
725
+ * contact is created if it does not exist yet, so this identifier is always
726
+ * resolvable against the contacts API.
586
727
  */
587
728
  contact_id?: string;
588
729
 
730
+ /**
731
+ * The contact's number, in E.164 format with the leading + — who raised the
732
+ * signal. The same party message.received publishes as inbound_number.
733
+ */
734
+ from?: string;
735
+
589
736
  /**
590
737
  * The inbound message that carried the signal, matching message_id on the
591
738
  * corresponding message.received event so the two can be joined.
@@ -599,10 +746,19 @@ export interface ContactEventPayload {
599
746
  message_id?: string | null;
600
747
 
601
748
  /**
602
- * The contact's number in E.164 format. Same value as phone_number on the contact
603
- * resource.
749
+ * The auto-reply template whose keyword the contact matched, joinable against the
750
+ * templates API.
751
+ *
752
+ * This is what identifies which signal arrived on contact.custom_keyword: every
753
+ * custom template reports the same event name, so the event alone cannot tell your
754
+ * booking keyword from your opening-hours one. One template holds as many keywords
755
+ * as you configured, so this is steadier to switch on than text.
756
+ *
757
+ * Populated on the compliance sub-types too, where it names the template that
758
+ * replied. Sent as null when no template was involved — a network-reported opt-out
759
+ * matches no keyword. The field is always present, so read it and check for null.
604
760
  */
605
- phone_number?: string;
761
+ template_id?: string | null;
606
762
 
607
763
  /**
608
764
  * The text the contact sent, for example STOP or UNSUBSCRIBE. Sent as null when
@@ -610,6 +766,22 @@ export interface ContactEventPayload {
610
766
  * check for null rather than checking whether the key exists.
611
767
  */
612
768
  text?: string | null;
769
+
770
+ /**
771
+ * The number of yours that received the signal, in E.164 format with the leading
772
+ * +. Tells a multi-number account which of its senders the contact acted on, which
773
+ * nothing else on this payload answers.
774
+ *
775
+ * This is your number, not the contact's. That is the opposite of what to means on
776
+ * POST /v3/messages, where it is the list of recipients you are sending to. Reply
777
+ * to From, not to this field, or the message goes back to yourself.
778
+ *
779
+ * Sent as null when the signal did not arrive at a number of yours — an RCS signal
780
+ * terminates at an agent rather than a number, and a provider-reported opt-out may
781
+ * name no receiving number at all. The field is always present, so read it and
782
+ * check for null rather than checking whether the key exists.
783
+ */
784
+ to?: string | null;
613
785
  }
614
786
 
615
787
  /**
@@ -808,6 +980,19 @@ export interface MessageEventPayload {
808
980
  */
809
981
  outbound_number?: string;
810
982
 
983
+ /**
984
+ * message.scheduled only: why the message is held, either because you scheduled it
985
+ * or because the recipient is inside a protected quiet-hours window. Omitted on
986
+ * every other event.
987
+ */
988
+ schedule_reason?: string | null;
989
+
990
+ /**
991
+ * message.scheduled only: when the held message will be released for delivery, in
992
+ * UTC (yyyy-MM-ddTHH:mm:ssZ). Omitted on every other event.
993
+ */
994
+ scheduled_at?: string | null;
995
+
811
996
  /**
812
997
  * The template the message was sent from, when it was sent from one.
813
998
  */
@@ -1104,11 +1289,30 @@ export interface WebhookListEventsResponse {
1104
1289
 
1105
1290
  /**
1106
1291
  * The exact event body that was delivered, or attempted, for this record. One of
1107
- * the four webhook envelopes: a message status change, an inbound message, a
1108
- * template status change, or a contact consent signal. Read field and event to
1109
- * tell which, the same way your endpoint does.
1110
- */
1111
- event_data?: MessageEvent | InboundMessageEvent | TemplateEvent | ChannelEvent | ContactEvent;
1292
+ * the six webhook envelopes:
1293
+ *
1294
+ * message — an outbound message changed status. message with event:
1295
+ * message.received — someone replied to you. templates — a template was approved,
1296
+ * rejected, paused or similar. channel — one of your markets moved in provisioning
1297
+ * or compliance. contact — a consent signal: opt-in, opt-out or help. link — a
1298
+ * tracked short link was clicked or a hosted file downloaded, or one expired or
1299
+ * was revoked.
1300
+ *
1301
+ * Read field and event to tell which, the same way your endpoint does. The two
1302
+ * message envelopes are the reason that is two fields and not one: they share a
1303
+ * field and differ by event.
1304
+ *
1305
+ * Treat the list as open. It has grown twice — channel and then link — and a
1306
+ * handler that rejects an envelope it does not recognise will break on the next
1307
+ * addition rather than ignore it.
1308
+ */
1309
+ event_data?:
1310
+ | MessageEvent
1311
+ | InboundMessageEvent
1312
+ | TemplateEvent
1313
+ | ChannelEvent
1314
+ | ContactEvent
1315
+ | WebhookListEventsResponse.SentDmServicesCommonServicesWebhooksContractsWebhookEventOfLinkWebhookPayload;
1112
1316
 
1113
1317
  event_type?: string;
1114
1318
 
@@ -1121,6 +1325,218 @@ export interface WebhookListEventsResponse {
1121
1325
  response_body?: string | null;
1122
1326
  }
1123
1327
 
1328
+ export namespace WebhookListEventsResponse {
1329
+ /**
1330
+ * The envelope Sent POSTs to a subscribed webhook endpoint. Every event shares
1331
+ * this shape and varies only in Payload.
1332
+ */
1333
+ export interface SentDmServicesCommonServicesWebhooksContractsWebhookEventOfLinkWebhookPayload {
1334
+ /**
1335
+ * The specific event within the family, for example message.delivered,
1336
+ * message.received or contact.opt_out. Absent on events that have no subtype, so
1337
+ * treat it as optional.
1338
+ */
1339
+ event?: string | null;
1340
+
1341
+ /**
1342
+ * The event family, for example message, templates or contact. Route on this
1343
+ * first, then on event for the specific change.
1344
+ */
1345
+ field?: string;
1346
+
1347
+ /**
1348
+ * Body of a link event: something happened to a tracked link Sent published on the
1349
+ * customer's behalf. A link points either at a URL the customer supplied or at a
1350
+ * file Sent hosts for them; LinkKind says which. Delivered when an eligible
1351
+ * request is served, or when a published link reaches the end of its life.
1352
+ *
1353
+ * A click is a request, not a read receipt. link.clicked means the redirect was
1354
+ * served; link.downloaded means bytes went out. Neither proves a person saw
1355
+ * anything — messaging providers and link scanners fetch URLs on their own, which
1356
+ * is what TrafficClass exists to tell apart. Filter on it before reporting a
1357
+ * click-through rate; treat likely_human as a hint, never as delivery
1358
+ * confirmation.
1359
+ *
1360
+ * RecordId identifies the link; the X-Webhook-Event-ID header identifies the
1361
+ * delivery. One link is hit many times, so those are the two keys a subscriber
1362
+ * needs: group by the first, deduplicate on the second — exactly as on every other
1363
+ * family. The payload carries no event identifier of its own, for the same reason
1364
+ * none of the others do.
1365
+ *
1366
+ * Nothing here identifies the visitor. No IP address and no visitor token crosses
1367
+ * this boundary. Country, Device and Browser are coarse buckets derived at the
1368
+ * edge and are absent whenever the request did not supply enough to derive them.
1369
+ */
1370
+ payload?: SentDmServicesCommonServicesWebhooksContractsWebhookEventOfLinkWebhookPayload.Payload | null;
1371
+
1372
+ /**
1373
+ * The event-specific body.
1374
+ */
1375
+ request_id?: string | null;
1376
+
1377
+ /**
1378
+ * When Sent emitted the event, in UTC (yyyy-MM-ddTHH:mm:ssZ). This is the emission
1379
+ * time, not the time the underlying change happened. Use the timestamp inside the
1380
+ * payload for the latter.
1381
+ */
1382
+ timestamp?: string;
1383
+ }
1384
+
1385
+ export namespace SentDmServicesCommonServicesWebhooksContractsWebhookEventOfLinkWebhookPayload {
1386
+ /**
1387
+ * Body of a link event: something happened to a tracked link Sent published on the
1388
+ * customer's behalf. A link points either at a URL the customer supplied or at a
1389
+ * file Sent hosts for them; LinkKind says which. Delivered when an eligible
1390
+ * request is served, or when a published link reaches the end of its life.
1391
+ *
1392
+ * A click is a request, not a read receipt. link.clicked means the redirect was
1393
+ * served; link.downloaded means bytes went out. Neither proves a person saw
1394
+ * anything — messaging providers and link scanners fetch URLs on their own, which
1395
+ * is what TrafficClass exists to tell apart. Filter on it before reporting a
1396
+ * click-through rate; treat likely_human as a hint, never as delivery
1397
+ * confirmation.
1398
+ *
1399
+ * RecordId identifies the link; the X-Webhook-Event-ID header identifies the
1400
+ * delivery. One link is hit many times, so those are the two keys a subscriber
1401
+ * needs: group by the first, deduplicate on the second — exactly as on every other
1402
+ * family. The payload carries no event identifier of its own, for the same reason
1403
+ * none of the others do.
1404
+ *
1405
+ * Nothing here identifies the visitor. No IP address and no visitor token crosses
1406
+ * this boundary. Country, Device and Browser are coarse buckets derived at the
1407
+ * edge and are absent whenever the request did not supply enough to derive them.
1408
+ */
1409
+ export interface Payload {
1410
+ /**
1411
+ * The link's public identifier — the eight-character code in the short URL, for
1412
+ * example A78B2BU0. Unique across both kinds, and never reused, so it is the
1413
+ * stable key to group one link's events by.
1414
+ */
1415
+ record_id: string;
1416
+
1417
+ /**
1418
+ * Where the request appeared to come from, as an ISO 3166-1 alpha-2 code. Named
1419
+ * separately from the country on a channel event, which is a destination market
1420
+ * the customer registered for — this one is a property of a single visitor and is
1421
+ * absent when the edge could not resolve it.
1422
+ */
1423
+ access_country?: string | null;
1424
+
1425
+ /**
1426
+ * How the request was served, when the edge recorded it. Free text describing the
1427
+ * outcome — show it to a human rather than branching on it.
1428
+ */
1429
+ access_outcome?: string | null;
1430
+
1431
+ /**
1432
+ * The requesting browser family, for example chrome or safari, or unknown. Derived
1433
+ * from the user agent.
1434
+ */
1435
+ browser?: string | null;
1436
+
1437
+ /**
1438
+ * How many bytes were served, for a file access. A ranged request reports the
1439
+ * bytes in that range, not the size of the file, so several accesses of one file
1440
+ * can each report a part.
1441
+ */
1442
+ bytes_served?: number | null;
1443
+
1444
+ /**
1445
+ * The channel the message carrying this link went out on: sms, whatsapp, or rcs.
1446
+ */
1447
+ channel?: string | null;
1448
+
1449
+ /**
1450
+ * The organization the link belongs to. Always the parent account, never a sender
1451
+ * profile — read SenderProfileId for that.
1452
+ *
1453
+ * This family publishes the owner as an explicit pair rather than the single
1454
+ * account_id the other families use. The pair says which organization and which
1455
+ * profile without the subscriber deriving either, which is the trade: one more key
1456
+ * against not having to know that account_id silently becomes the profile when one
1457
+ * exists.
1458
+ */
1459
+ customer_id?: string;
1460
+
1461
+ /**
1462
+ * The requesting device class: mobile, tablet, desktop or unknown. Derived from
1463
+ * the user agent.
1464
+ */
1465
+ device?: string | null;
1466
+
1467
+ /**
1468
+ * What the link points at: url for a destination the customer supplied, file for
1469
+ * media Sent hosts. Always present, and implied by the event — link.clicked is
1470
+ * always url and link.downloaded always file — but published as its own field so a
1471
+ * subscriber can branch on the kind without parsing the event name, the same
1472
+ * separation the channel family keeps between its event and its status.
1473
+ */
1474
+ link_kind?: string;
1475
+
1476
+ /**
1477
+ * The message the link was published in.
1478
+ *
1479
+ * The event can arrive before the message is readable through GET /v3/messages: a
1480
+ * provider may fetch a link within milliseconds of the send, and nothing here
1481
+ * waits for the message row. Retry the read rather than treating an unknown id as
1482
+ * an error.
1483
+ */
1484
+ message_id?: string | null;
1485
+
1486
+ /**
1487
+ * When the access or lifecycle change actually happened, in UTC
1488
+ * (yyyy-MM-ddTHH:mm:ssZ). The envelope's timestamp is when Sent emitted the event;
1489
+ * this is when the thing occurred, and the two differ by the ingest delay.
1490
+ */
1491
+ occurred_at?: string;
1492
+
1493
+ /**
1494
+ * The caller-supplied label tying this link back to a position in the message, for
1495
+ * example body:0 for the first link in the body. Present when the link was created
1496
+ * with one.
1497
+ */
1498
+ reference_key?: string | null;
1499
+
1500
+ /**
1501
+ * The host of the page that linked here, when the request supplied one. The host
1502
+ * only — never a full referring URL.
1503
+ */
1504
+ referrer_host?: string | null;
1505
+
1506
+ /**
1507
+ * The HTTP method of the request that was served, for an access event. Omitted on
1508
+ * link.expired and link.revoked, which describe no request.
1509
+ */
1510
+ request_method?: string | null;
1511
+
1512
+ /**
1513
+ * The sender profile that owns the link, or null when the organization owns it
1514
+ * directly. Always on the wire so a handler reads one shape rather than branching
1515
+ * on whether the key arrived.
1516
+ *
1517
+ * sender_profile_id, not profile_id: the API already publishes
1518
+ * messaging_profile_id and sending_phone_number_profile_id for provider-side
1519
+ * profiles, which are a different thing entirely. The unqualified name would read
1520
+ * as one of those.
1521
+ */
1522
+ sender_profile_id?: string | null;
1523
+
1524
+ /**
1525
+ * The HTTP status Sent answered the request with: 302 for a link, 200 or 206 for a
1526
+ * file. Omitted on lifecycle events.
1527
+ */
1528
+ status_code?: number | null;
1529
+
1530
+ /**
1531
+ * A coarse guess at what made the request: likely_human, provider (a messaging
1532
+ * platform prefetching the link), bot, or unknown. Derived from the user agent, so
1533
+ * it is a hint for filtering noise rather than a fact to bill or report on.
1534
+ */
1535
+ traffic_class?: string | null;
1536
+ }
1537
+ }
1538
+ }
1539
+
1124
1540
  /**
1125
1541
  * Standard API response envelope for all v3 endpoints
1126
1542
  */
package/src/version.ts CHANGED
@@ -1 +1 @@
1
- export const VERSION = '0.39.0'; // x-release-please-version
1
+ export const VERSION = '0.40.0'; // x-release-please-version
package/version.d.mts CHANGED
@@ -1,2 +1,2 @@
1
- export declare const VERSION = "0.39.0";
1
+ export declare const VERSION = "0.40.0";
2
2
  //# sourceMappingURL=version.d.mts.map
package/version.d.ts CHANGED
@@ -1,2 +1,2 @@
1
- export declare const VERSION = "0.39.0";
1
+ export declare const VERSION = "0.40.0";
2
2
  //# sourceMappingURL=version.d.ts.map
package/version.js CHANGED
@@ -1,5 +1,5 @@
1
1
  "use strict";
2
2
  Object.defineProperty(exports, "__esModule", { value: true });
3
3
  exports.VERSION = void 0;
4
- exports.VERSION = '0.39.0'; // x-release-please-version
4
+ exports.VERSION = '0.40.0'; // x-release-please-version
5
5
  //# sourceMappingURL=version.js.map
package/version.mjs CHANGED
@@ -1,2 +1,2 @@
1
- export const VERSION = '0.39.0'; // x-release-please-version
1
+ export const VERSION = '0.40.0'; // x-release-please-version
2
2
  //# sourceMappingURL=version.mjs.map