Marketing Message Test

marketing-message-test: E360 Message Preview & Test Send

Render a per-channel preview (or fire a test send) for a Marketing Cloud / Engagement 360 message, headlessly, starting from a single contentKey. Covers all six channels: Email, SMS, WhatsApp, Push, In-App, RCS.

Full endpoint tables, request bodies, response-field rules, and the version-floor matrix live in references/api-contract.md. This file is the operating procedure; consult the reference for exact payloads.

When This Skill Owns the Task

Use marketing-message-test when the user wants to:

• render how an authored message looks for a real recipient (personalized preview)
• render content-only with no recipient (unpersonalized preview)
• send a test message to their own address / phone / individual id

Delegate elsewhere when the user is:

• building Data Cloud segments or calculated insights → data360-segment
• building DMOs, mappings, or identity resolution → data360-harmonize
• activating a segment downstream → data360-activate

Required Context to Gather First

• contentKey — required, irreducible. The caller must supply it; it is not derivable.
• target org alias (for sf org open / access token)
• channel — Email, SMS, WhatsApp, Push, In-App, or RCS
• mode — personalized preview, unpersonalized preview, or test send
• for a test send only: the user's own destination(s) — toAddresses (Email), toPhoneNumbers (SMS/WhatsApp/RCS), or toIndividualIds (Push/In-App). Never derive these.

Transports

Versions:

• LWR-Apex — not version-gated; pin v68.0 (the path just needs a well-formed vXX.0 segment).
• Connect REST — real per-resource floors; highest is data-spaces at v62.0, so v62.0+ covers all six channels (others lower — see the reference floor matrix).

Always use sf api request rest — never curl. It attaches the org's bearer token internally, so the credential never enters your context. Never extract a token (e.g. sf org display --json) or put one in an Authorization header — that leaks a live credential and is disallowed. Pass the instance-relative path (no host); the CLI prepends the instance URL and accepts both transports (LWR-Apex paths aren't under services/data/, but any instance-relative path works). One step is the exception — whatsapp-template-fetch is a headless /headless/invoke dispatch route, invoked through the dispatch tool rather than sf api request rest.

# GET (default method); path is instance-relative
sf api request rest 'services/data/v63.0/ssot/data-spaces' --target-org <org>

# POST with a flat JSON body from a file (content-type: application/json is sent by default)
# path = the target operation's **Call** line (e.g. the `preview-sms-unpersonalized` step)
sf api request rest '<lwr/apex Call path>' \
  --target-org <org> --method POST --body @body.json

Verb rule (do not violate — wrong verb is rejected):

• Preview / test-send methods are POST (--method POST) with a flat JSON body whose keys are exactly the parameter names — no envelope, no wrapper object.
• Sender / permission lookups are GET (default method) with args packed into a single methodParams query param (URL-encoded JSON string) appended to the path; no-arg methods omit it.

Core Operating Rules

• Never fabricate a segmentId, profileId, DMO name, or destination. Every value is either given by the user or derived from the org via the chain below.
• Preview needs no sender — skip sender lookups (Part 3 of the reference) unless test-sending.
• Personalized vs unpersonalized: unpersonalized needs only contentKey; personalized needs segmentId + recipientDataModelObjectName + contentKey + profileId, and the profileId must be a member of that segmentId (it comes from that segment's member list — see the chain).
• Personalization is supported ONLY with a valid segment and a member of it. The recipient (profileId) comes solely from the chosen segment's member list, and must be a member of the segmentId passed to the render. If the segment has no members — or no segment exists in the content's data space — the personalization render cannot be performed: report cannot personalize — no valid segment member and stop. The unpersonalized preview (contentKey only) is still available; offer it. Never source the recipient from anywhere else (e.g. by listing individuals from the DMO) — a non-member profileId is rejected by the render with an opaque error.
• A test send is a real send to the supplied destinations — confirm the user asked for it and has provided their own destinations before firing any test send (the send-test-… steps). If the user asked only to preview, never fire a test send.
• Check send permission before every test send. Before firing any send-test-<channel>, call that channel's permission check (step perm-can-send-test-<channel> — a no-arg GET returning a Boolean). If it returns false, surface a permission error and stop — do not attempt the send. Preview never needs this check.
• profileId is a Data Cloud profile key (e.g. a1b2c3d4…), NOT a CRM id (003…) or a segment id (1sg…).
• Run the derivation yourself end to end via sf api request rest; don't hand the user raw commands to run.

Derivation Chain (personalized preview / test send, from contentKey)

Detailed payloads for every step: references/api-contract.md.

1. Fetch content — GET /services/data/vXX.0/connect/cms/contents/{contentKey} (v57+) → managedContentId, contentBody. Use the CMS Authoring API (keyed by contentKey), not the delivery API — it returns the draft the preview renders.
2. Recipient DMO (from content) → recipientDataModelObjectName. Parse contentBody['lightning:dataProviders'] for objectApiName (that is the DMO) or dataGraphApiName — for the latter, GET /ssot/data-graphs/{dataGraphApiName} (v58+) and read primaryObjectName (its response also returns dataspaceName, usable directly in step 3). If the content declares no data provider, leave the DMO unresolved for now — it comes from the org fallback in step 3, which needs the data space first.
3. Data space → dataSpaceName (scopes every /ssot/… call below). GET /ssot/data-spaces (v62+).
   • DMO declared in step 2 — derive the data space from the DMO name: ssot__… prefix or an unrecognized name → default; a <prefix>_ token → match against the prefix field and take that entry's name. default on single-space orgs.
   • No DMO declared — there's no name to match, so choose the data space first: default on a single-space org, otherwise ask the user which space. Then resolve the DMO from the org via the org-fallback lookup (step messaging-selected-uma-dmo, body { dataSpaceName }). A null result means "no personalized preview available for this org" — report that, do NOT retry.
4. Segment → GET /ssot/segments?dataspace=<name> (v55+). Keep the apiName (fetches members) and the 1sg… marketSegmentId (the segmentId).
5. profileId — from the chosen segment's members, the only valid source:
   • GET /ssot/segments/{segmentApiName}/members?limit=10&dataspace=<name> (v58+) → member id. That id is the profileId; because it's a member of the segment, the render accepts it.
   • If the member list is empty (or no segment exists in the data space), stop — personalization cannot be performed. There is no valid recipient: report cannot personalize — no valid segment member and offer the unpersonalized preview instead. Do not source the recipient elsewhere (e.g. by listing individuals from the DMO) — a profileId that isn't a member of the passed segmentId is rejected by the render with an opaque error.
6. Render — call the channel's personalized-preview operation (step preview-<channel>-personalized, or the …-by-locale variant) with the flat body { segmentId, recipientDataModelObjectName, contentKey, profileId, … }.

Unpersonalized short-circuits after step 1: call the channel's unpersonalized-preview operation (step preview-<channel>-unpersonalized) with { contentKey } (add locale for Email's …-by-locale variant).

Test send = the channel's permission check (step perm-can-send-test-<channel>; stop if false), then steps 1–6, then a sender lookup (Part 3 of the reference) for fromAddress/senderId, then the channel's test-send operation (step send-test-<channel>) with the user's supplied destination array.