@outseta/react 0.4.9 → 0.4.10

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@outseta/react",
3
- "version": "0.4.9",
3
+ "version": "0.4.10",
4
4
  "description": "React hooks and components for the Outseta API",
5
5
  "license": "MIT",
6
6
  "repository": {
@@ -18,7 +18,7 @@
18
18
  }
19
19
  },
20
20
  "dependencies": {
21
- "@outseta/api-client": "0.3.15"
21
+ "@outseta/api-client": "0.3.16"
22
22
  },
23
23
  "peerDependencies": {
24
24
  "react": "^18.0.0 || ^19.0.0"
@@ -821,19 +821,27 @@ still be supplied directly (a JSON string of the form
821
821
  {"BroadcastRecipientsEmailLists":[{"Uid":"..."}],"BroadcastRecipientsSegments":[{"Uid":"..."}]});
822
822
  when both are present they are merged.
823
823
 
824
- Message.Body is the complete HTML email and is exactly what gets sent. It is rendered as a
825
- Liquid template, so it may include merge tags such as {{ Person.FirstName }}; unknown {{ }}
826
- tokens render as empty text. An inline-styled HTML fragment is recommended, though a full
827
- HTML document is also accepted. Message.Design (the drag-and-drop editor state) is optional —
828
- when omitted it is generated automatically from Body, so callers (including LLM tools) do not
829
- need to understand it. Use Message.PreviewText for inbox preview text rather than an in-body
824
+ Message.Body is rendered as a Liquid template, so it may include merge tags such as
825
+ {{ Person.FirstName }}; unknown {{ }} tokens render as empty text. An inline-styled HTML
826
+ fragment is recommended. Message.Design (the drag-and-drop editor state) is optional — when
827
+ omitted it is derived automatically, so callers (including LLM tools) do not need to
828
+ understand it. Use Message.PreviewText for inbox preview text rather than an in-body
830
829
  preheader.
831
830
 
832
- You must include a visible unsubscribe link in the body yourself: add {{ UnsubscribeLink }}
833
- (a ready-made anchor) or {{ UnsubscribeUrl }} (the raw URL) where you want it. One is not
834
- inserted automatically, and its presence is not validated. A one-click List-Unsubscribe
835
- header is always added, but most anti-spam laws (e.g. CAN-SPAM) also require a visible
836
- unsubscribe link in the body.
831
+ When Body is a bare content fragment (no Design and no unsubscribe token), it is composed
832
+ into the account's API email layout — a branded header and footer that includes the
833
+ unsubscribe and manage-subscriptions links — and the composed result is what is sent and
834
+ opened in the editor. The layout is editable in the app; TemplateUid selects a specific
835
+ layout template when the account has more than one.
836
+
837
+ The layout is NOT applied when the body already contains an unsubscribe token
838
+ ({{ UnsubscribeLink }}, {{ UnsubscribeUrl }} or {{ OneClickUnsubscribeUrl }}), when a
839
+ Design is supplied, or when the body is a complex full HTML document (Outlook conditional
840
+ comments, stylesheet links) — in those cases the body is sent exactly as supplied, and you
841
+ must include a visible unsubscribe link in it yourself: add {{ UnsubscribeLink }} (a
842
+ ready-made anchor) or {{ UnsubscribeUrl }} (the raw URL) where you want it. Its presence is
843
+ not validated. A one-click List-Unsubscribe header is always added, but most anti-spam laws
844
+ (e.g. CAN-SPAM) also require a visible unsubscribe link in the body.
837
845
  * @summary Create a new broadcast.
838
846
  */
839
847
  export const campaignAddBroadcastEmail = (
@@ -976,8 +984,11 @@ set, send RecipientData directly.
976
984
 
977
985
  When changing Message.Body, omit Message.Design: it is regenerated from the new Body so the
978
986
  drag-and-drop editor stays in sync. Sending a Design that was captured from an earlier
979
- response alongside an edited Body would otherwise keep the stale design. See the create
980
- endpoint for how Body is rendered (Liquid) and the unsubscribe-token expectation.
987
+ response alongside an edited Body would otherwise keep the stale design. A body that was
988
+ composed into the API email layout keeps the layout on such updates without duplicating
989
+ it — its content is re-composed into the layout — and a bare fragment is composed like on
990
+ create. See the create endpoint for how Body is rendered (Liquid), when the layout
991
+ applies, and the unsubscribe-token expectation when it does not.
981
992
  * @summary Update a broadcast.
982
993
  */
983
994
  export const campaignUpdateBroadcastEmail = (
@@ -4189,6 +4189,8 @@ export type BroadcastCampaignAllOf = {
4189
4189
  EmailListUids?: string[] | null;
4190
4190
  /** @nullable */
4191
4191
  SegmentUids?: string[] | null;
4192
+ /** @nullable */
4193
+ TemplateUid?: string | null;
4192
4194
  Status?: BroadcastCampaignStatus;
4193
4195
  /**
4194
4196
  * @maxLength 500