Sailthru Integration Overview

How Wunderkind Integrates With Sailthru

The Sailthru integration with Wunderkind enables us to:

• Collect and send new email addresses to Sailthru in real time

• Verify subscription / mailability status before sending an email

• Determine customer status (prospect vs. customer) from Sailthru profile data

• Update unsubscribe status when users opt out via Wunderkind emails

• Deploy triggered emails via Sailthru (Client Sender) or via Wunderkind’s ESP

• Identify returning users from Sailthru emails using URL appending

This guide includes an overview of everything that Wunderkind can and cannot support, considerations, and requirements placed on us by Sailthru.

Wunderkind requires admin/API access to Sailthru (API key + secret) in order to build and test our integration with your Sailthru instance.

Table of Contents:

1. Authentication

2. Writing New Subscribers

3. Checking Customer Status

4. Checking Mailability

5. Updating Unsubscribe Status

6. Sender Options

7. URL Appending

8. Important Callouts

1. Authentication

In order to authenticate our API calls, Wunderkind uses your Sailthru API key and secret.

All requests are sent over HTTPS to:

https://api.sailthru.com/{endpoint}

Each request includes:

• api_key – your Sailthru API key

• sig – an MD5 signature derived from your API secret and request parameters

• format – typically json

• json – a JSON object containing the request body

Example (conceptual)

POST https://api.sailthru.com/user
api_key={API_KEY}
sig={MD5_SIGNATURE}
format=json
json={"id":"user@example.com","lists":{"Main Newsletter":1}}

Wunderkind will:

• Store your API key and secret securely in our backend

• Respect any IP allowlists you’ve configured (we can provide static IPs if needed)

2. Writing New Subscribers

Upon email submission, Wunderkind will write new subscribers to Sailthru by:

1. Creating or updating a user profile via /user

2. Subscribing the user to one or more lists

3. Optionally setting vars such as subscribe_source = "wunderkind" and other agreed attributes

By default, Wunderkind uses email as the primary key, but we can work with other keys (e.g. extid, sid) if agreed during implementation.

Wunderkind does not manage bulk imports; large historical lists should be loaded directly into Sailthru via their UI or Job API.

API Calls for Writing New Subscribers

Request

POST /user
Host: https://api.sailthru.com

Body

{
  "id": "wknd+104@blackhole.ibx2.net",
  "keys": {
    "email": "wknd+104@blackhole.ibx2.net"
  },
  "lists": {
    "Main Newsletter": 1
  },
  "vars": {
    "subscribe_source": "wunderkind",
    "signup_timestamp": "2025-09-16T17:04:15+00:00"
  }
}

Notes

• id / keys.email – the user’s email address (default key)

• lists – 1 subscribes the user to that list (e.g. Main Newsletter)

• vars – any custom profile fields to store acquisition details, consent source, locale, etc.

• If the user already exists, the profile is updated; if not, Sailthru creates a new profile (upsert behavior).

3. Checking Customer Status

Wunderkind uses Sailthru data to distinguish prospects from customers for segmentation (e.g. customer vs. prospect flows).

We do this by querying the user profile via /user and examining the purchases field only (per internal Sailthru integration specs).

API Calls for Checking Customer Status

Request

GET /user
Host: https://api.sailthru.com

Body

{
  "id": "test@test.com",
  "fields": {
    "purchases": 1
  }
}

Default behavior

• If purchases contains at least one entry → user is treated as a customer

• If purchases is empty or missing → user is treated as a prospect

If your data model uses an additional customer flag (for example, a specific profile var or list membership), Wunderkind can layer that on top of the purchases‑based rule as part of your implementation spec.

4. Checking Mailability

Before sending any triggered email (via Sailthru Client Sender or Wunderkind Sender), Wunderkind checks the user’s mailable status in Sailthru.

Sailthru stores email opt‑out state in the optout_email field on the user profile:

• "none" – fully mailable

• "basic" – opted out of marketing emails (may still receive certain transactional emails, depending on your setup)

• "all" – fully opted out of all emails from the brand

API Calls for Checking Mailability

Request

GET /user
Host: https://api.sailthru.com

Body

{
  "id": "sample@hotmail.com",
  "key": "email",
  "fields": {
    "optout_email": 1
  }
}

Default behavior

• If optout_email = "none" → user is mailable

• If optout_email is "basic" or "all" → user is not mailable

If you require strict opt‑in logic (e.g. user must be on a specific list or have an explicit consent flag) instead of using optout_email, Wunderkind can incorporate those rules as part of your implementation, with the tradeoff that fewer users may be considered mailable.

5. Updating Unsubscribe Status

If a user unsubscribes from a Wunderkind email, Wunderkind updates their Sailthru profile to reflect the new opt‑out state.

We typically record the unsubscribe in Sailthru via /user and can include additional metadata such as unsubscribe_source.

API Calls for Updating Unsubscribe Status

Request

POST /user
Host: https://api.sailthru.com

Opt out of all email

{
  "id": "bouncex123@gmail.com",
  "key": "email",
  "optout_email": "all",
  "vars": {
    "unsubscribe_source": "Wunderkind"
  }
}

Opt out of marketing only (retain transactional)

{
  "id": "bouncex123@gmail.com",
  "key": "email",
  "optout_email": "basic",
  "vars": {
    "unsubscribe_source": "Wunderkind"
  }
}

Notes

• optout_email – controls the opt‑out level:

  • "none" – no opt‑out

  • "basic" – marketing opt‑out

  • "all" – full opt‑out

• vars.unsubscribe_source – optional, used to track that the unsubscribe originated from Wunderkind.

Sailthru can also send postbacks to your systems; Wunderkind does not require those for the integration but can coexist with them.

6. Sender Options

Wunderkind can deploy emails in two ways:

1. Client Sender (Sailthru Sender) – emails are sent from your Sailthru account

2. Wunderkind Sender – emails are sent from Wunderkind’s ESP (SendGrid)

Client Sender

With a Client Sender integration:

• Wunderkind hosts email HTML and logic (triggers, personalization).

• Wunderkind sends fully rendered HTML and metadata to Sailthru.

• Sailthru is responsible for:

  • Final delivery

  • Opens/click tracking

  • Reporting in your existing Sailthru dashboards

Template setup (high‑level)

In Sailthru:

1. Go to Messaging → Templates

2. Create an HTML Email template (e.g. cartabandonment-customers-1)

3. In the Code tab, include placeholders for the rendered HTML and any tracking code:

   {full_html}
   <p style="display:none!important;color:white;">
     <small>
       If you believe this has been sent to you in error, please safely
       <a style="display:none!important;" href="{optout_confirm_url}">unsubscribe</a>.
     </small>
   </p>
   <img src="{beacon_src}" style="display:none!important;" />
   

4. (Optional) Apply a label such as Wunderkind so all related templates are easy to find.

Wunderkind then maps each triggered series (e.g. Cart Abandonment – Customers – Email 1) to a specific Sailthru template.

Client responsibilities

• Confirm:

  • From / Reply‑To address (e.g. email@clientname.com)

  • Template naming convention and folder/label usage

• Coordinate with your Sailthru team on any additional flags or template logic.

Wunderkind Sender

With Wunderkind Sender:

• Emails are sent via Wunderkind’s ESP (SendGrid).

• Sailthru is still used for:

  • Writing new subscribers

  • Mailability checks

  • Unsubscribe updates

You do not need to configure Sailthru templates for these emails, but you should still implement URL appending so clicks from Sailthru‑sent marketing messages can be used for identification.

7. URL Appending

URL appending is one of Wunderkind’s most impactful identification methods. It allows us to:

• Identify users returning from Sailthru marketing emails

• Map a non‑PII identifier in the URL back to a known email address inside Wunderkind

For Sailthru, we typically use a parameter like bxid with the Sailthru profile ID (or another agreed, stable user ID).

URL Appending Configuration

In Sailthru:

1. Go to Messaging → Templates

2. Open a template used for marketing sends

3. Click the gear icon in the top‑right

4. Under Content & Personalization → Auto‑Append Link Parameters, add:

   bxid={profile.id}

5. Save the template and repeat for all applicable templates

Example resulting URL:

https://www.yoursite.com/landing-page?utm_medium=email&bxid=586441f6a79328d4708b55a7

Notes

• bxid – holds a non‑PII user identifier (e.g. Sailthru profile.id)

• Wunderkind uses this identifier in a secure mapping to retrieve the associated email address

• You may choose a different parameter name, but the value must be a stable, unique ID

(If desired, we can also discuss a lookup call pattern for this ID; by default, Wunderkind handles the mapping internally.)

8. Important Callouts

• Admin/API access
  Wunderkind must have access to your Sailthru API key and secret to build the integration.

• Opt‑in vs. Opt‑out

  • By default, we use optout_email to determine mailability.

  • If you want a stricter opt‑in model (e.g. only send to users in a consented list), we can configure that, with an impact on reachable audience size.

• Transactional vs. marketing

  • Sailthru supports different treatment for transactional and marketing emails.

  • If desired, Wunderkind can restrict updates to marketing opt‑out only and leave transactional sends unaffected.

• Client Sender specifics

  • All deliverability, tracking, and reporting for Client Sender emails live in Sailthru.

  • Before launch, we will run test sends and confirm:

    • Correct From/Reply‑To

    • Correct template usage

    • Proper logging and reporting in Sailthru

• URL appending is critical
  Without bxid={profile.id} (or an equivalent identifier) appended to Sailthru links, Wunderkind cannot fully leverage click‑through identification, which is a major contributor to performance uplift.