circle-exclamation
This documentation is currently under development. Certain sections are not yet complete and will be added shortly.

Adobe Marketing Cloud

Send The Wallet Crew transactional emails via Adobe Journey Optimizer, Adobe Campaign, or Marketo Engage using the script email provider.

Use this integration when you want The Wallet Crew to send transactional emails through an Adobe marketing product your Brand already uses.

“Adobe Marketing Cloud” is not a single email product. Email sending depends on what you run in Adobe:

This is a script-based connector. The Wallet Crew still renders email content if you want it to. Your script then delegates the final delivery to Adobe.

You can use two delivery models:

  • The Wallet Crew renders HTML, and Adobe sends it.

  • Adobe renders the template, and The Wallet Crew only sends variables.

The architecture stays the same in all cases.

  • A retail Brand uses AJO for orchestration, consent, and reporting. The Wallet Crew provides the final HTML.

  • A Brand already has Adobe Campaign Transactional Messaging in production. They keep governance and reporting there.

  • A team uses Marketo Engage for marketing automation and wants transactional sends visible in Marketo activity logs.

  • A security team requires all outbound emails to go through a single audited platform. The script provider enforces that.

Before you start

You must implement the script interface described in EmailSender extensibility. This page focuses on what changes when the “provider behind the script” is Adobe.

You will also need access to your Adobe product to create and publish whatever is required to send emails (campaign, event, or template). The Wallet Crew cannot create those objects for you.

circle-info

If you already send emails from Adobe and only want to embed “Add to Wallet” links, you don’t need this page. Use your Adobe templates and place The Wallet Crew links behind your CTAs. See Enroll > Via Email for that approach.

Pick your Adobe product

Each Adobe product has its own API, assets, and governance model. Pick the one your organization already runs.

circle-exclamation

Enable the script email provider in The Wallet Crew

This is the switch that makes The Wallet Crew call your SendEmail implementation.

1

Implement runtime.scriptable.emailEngine.SendEmail

Start from EmailSender extensibility and add your Adobe delivery code inside SendEmail.

Make sure your script can access Adobe credentials securely. Do not hardcode secrets in the script.

2

Update /server/emails.yml

Open the advanced configuration editor, then create or edit /server/emails.yml.

Set the provider type to script. Keep resources pointing to your email template directory.

3

Trigger one transactional email and verify in Adobe

Trigger a real email (pass download link, verification email, or registration email).

Verify that Adobe receives the call and that the message is accepted. Then validate delivery in mailbox headers if needed (SPF/DKIM/DMARC).

Template and culture strategy

The Wallet Crew can render templates locally via buildEmail. Adobe can also render templates on its side, depending on the product.

Pick one of these models and keep it consistent:

  • The Wallet Crew owns the HTML. You send rendered Subject and Body to Adobe.

  • Adobe owns the HTML. You send only variables, and Adobe picks the template.

Culture selection remains your responsibility. The platform provides a cultures array. Common strategies include selecting the first culture, mapping a culture to a specific Adobe asset, or falling back to a default.

Security and privacy notes

Treat this integration as a server-to-server connection.

  • Keep all Adobe credentials server-side. Never expose them to customers.

  • Prefer short-lived access tokens. Rotate client secrets regularly.

  • Avoid logging full rendered email bodies. Email content can contain personal data.

  • Log stable identifiers instead (template name, Adobe campaign/event id, and a correlation id).

Troubleshooting

If emails stop sending, isolate the issue in this order:

  • Confirm /server/emails.yml is valid YAML and saved in the right tenant.

  • Confirm your script registers runtime.scriptable.emailEngine and exports SendEmail.

  • Confirm Adobe authentication works (token generation and scopes).

  • Confirm the Adobe asset is published and callable (campaign/journey/event/template).

  • Check Adobe logs for rejected requests (missing fields, schema mismatch, rate limits).

FAQ

chevron-rightWhich option should we choose?hashtag

Pick the product your organization already runs and governs for transactional emails. If you have Adobe Journey Optimizer available for API-triggered sends, it is usually the most future-proof choice.

chevron-rightCan we switch later?hashtag

Yes. Rendering is separated from delivery. If you keep your templates in The Wallet Crew, switching the downstream Adobe product mostly becomes a script change.

chevron-rightDo we need Adobe to host templates?hashtag

Not necessarily. You can send fully rendered HTML from The Wallet Crew, or delegate rendering to Adobe. Pick one strategy to avoid inconsistencies.

chevron-rightDo we need this integration if we already send emails from Adobe?hashtag

Not always. If your Brand already sends the email from Adobe and you only want to add “Add to Wallet” links, keep the email fully in Adobe. Then embed The Wallet Crew links behind your CTAs. See Enroll > Via Email for that approach.

Use the script provider only when you want The Wallet Crew to trigger the transactional send and delegate final delivery to Adobe.

chevron-rightShould we send rendered HTML or only variables?hashtag

Send rendered HTML when you want The Wallet Crew to be the source of truth for email content and translations. Send only variables when your email team needs full control of the template and approval workflow in Adobe.

Avoid mixing both models across journeys. It creates hard-to-debug differences between emails.

chevron-rightCan we use multiple Adobe products at the same time?hashtag

Technically yes, because your script can route sends however you want. In practice, pick one product per tenant when possible. It keeps governance, reporting, and troubleshooting clear.

Last updated