Forem: Jan Hjørdie

Integrating Campaign Monitor Smart Emails (Transactional) — Minimal Guide

Jan Hjørdie — Tue, 25 Nov 2025 13:58:42 +0000

This short guide describes a minimal, robust integration pattern for sending Campaign Monitor Smart (transactional) emails from a .NET application. It documents practical pitfalls and how the example CampaignMonitorService addresses them.

Note: all examples below use placeholders (no real API keys, email addresses, or list IDs).

Authentication

Campaign Monitor uses Basic Auth for all API calls. Use the API key as the username and any non-empty string (for example x) as the password.
There is no separate transactional API key; the same key used for classic APIs also works for transactional Smart Email endpoints.

Example header (curl style):

# placeholder values
API_KEY=<YOUR_API_KEY>
SMART_ID=<YOUR_SMART_EMAIL_ID>

curl -u "$API_KEY:x" \
  -H "Content-Type: application/json" \
  -d '{"To":["<recipient_placeholder>"],"Data":{"Subject":"Test"},"ConsentToTrack":"Yes"}' \
  https://api.createsend.com/api/v3.3/transactional/smartEmail/$SMART_ID/send

Key implementation notes

Authentication precedence: prefer an explicit transactional API key if present, otherwise fall back to the general API key or the first configured client key.
Base URL normalization: some environments reference transact.createsend.com which can cause TLS subjectAltName mismatches. Normalize transactional calls to api.createsend.com to avoid local TLS errors.
Development TLS helper: a SkipCertificateValidation option can be enabled only in development to bypass name-mismatch TLS errors. Do not enable in production.

Smart Email payload shape

Smart Email sends are POSTs to /transactional/smartEmail/{SMART_ID}/send.
The JSON payload should contain:
- To: array of recipient addresses
- Data: object with variables available to the Smart Email template (Liquid)
- ConsentToTrack: commonly required by templates/accounts (values: "Yes" or "No")

Example payload (placeholder values):

{
  "To": ["<recipient_placeholder>"],
  "Data": { "Subject": "My Subject", "EventsList": "<html string>" },
  "ConsentToTrack": "Yes"
}

Sending strategy implemented in `CampaignMonitorService`

SendTransactionalEmailWithEventsAsync:
- If a Smart Email id is supplied (or configured globally), it sends to the Smart Email transactional endpoint using the Data payload.
- If no Smart Email id exists, it falls back to a legacy transactional API path.
- The method handles empty response bodies (202 Accepted) and attempts to parse returned JSON when available.
SendTransactionalEmailWithEventsToListAsync (bulk list send):
- Pages the classic API endpoint lists/{listId}/active.json to collect active subscribers.
- De-duplicates recipients and chunks them into batches (default 200 recipients per batch).
- Sends each chunk as a separate Smart Email request.
- Returns a summary response containing counts of sent/failed batches and the last raw response body for troubleshooting.

Robust subscriber parsing

Some Campaign Monitor responses contain fields in unexpected formats. A common example is the Date field in list subscribers: it may be an empty string or a non-ISO value.
To avoid deserialization failures, parse the Results array manually and only attempt to parse Date when the value is non-empty and parseable. Malformed or empty dates should be treated as null.

HTML generation for list data

If you need to provide rendered HTML to a Smart Email template (for example a generated events list), produce a small, escaped HTML fragment (for example a <ul> with encoded text) and pass it as a Liquid variable in Data (the example uses EventsList).

Batching, throttling and retries

Default batch size in the example is 200 recipients. This keeps payloads manageable.
If you observe 429 or 5xx responses, add a delay between batches (or exponential backoff) and/or retries for failed batches.
Log batch-level results to spot systemic failures and to decide if retrying is appropriate.

Simple backoff example (concept):

// between batches
await Task.Delay(TimeSpan.FromMilliseconds(500));
// implement retry with exponential backoff for failed batch responses

Logging and diagnostics

Log which credential source is used (but mask keys in logs).
Log the transactional client's Authorization header presence (mask preview) and the target BaseAddress.
Preserve RawBody of responses when present to aid debugging.

Example (C#) — sanitized

Below is a minimal example showing how a caller might use the helper that sends to a list. All values are placeholders.

// assumed injected: CampaignMonitorService cmService

var events = Enumerable.Range(1, 5)
    .Select(i => new CampaignMonitorService.EventInfo(DateTime.Today.AddDays(i), $"Event {i}", $"Desc {i}"))
    .ToList();

var listId = "<LIST_ID_PLACEHOLDER>";
var response = await cmService.SendTransactionalEmailWithEventsToListAsync(
    listId: listId,
    events: events,
    subject: "Upcoming Events",
    smartEmailId: null, // use configured default if null
    text: "Optional plain text",
    batchSize: 200
);

if (response != null)
    Console.WriteLine($"Send result: {response.Status}");
else
    Console.WriteLine("No recipients found or send failed.");

Testing helpers

Use a dry-run script or curl to validate payload shapes before executing real sends.
Keep ConsentToTrack in the payload during testing to avoid 400 errors when the template expects consent.

This pattern and the defensive parsing/normalization steps make a Smart Email integration more resilient to real-world quirks: TLS host oddities, empty response bodies, non-standard JSON fields, and the need to send to multiple recipients in a controlled, observable way.

Real Blazor WebAssembly Production Pitfalls

Jan Hjørdie — Sat, 22 Nov 2025 20:08:04 +0000

Real Blazor WebAssembly Production Pitfalls

(With Google Maps as a Case Study)

Blazor WebAssembly works beautifully in development — but the moment you publish a Release build with PublishTrimmed=true, you start seeing an entirely different runtime behavior:

Features that worked locally stop working
External SDKs fail without console errors
JS interop calls disappear into the void
Reflection stops working
Maps, charts, and 3rd‑party UI break silently

This blog post is a deep, technical walkthrough of the real pitfalls you hit when you move Blazor WASM into production — with Google Maps (Advanced Markers + MapId/StyleId + lazy load) as a concrete case study.

This is not theory.

This is what actually breaks when you ship.

1. Trimming Removes .NET Methods Used by JS Interop

Blazor’s linker (ILLink) removes all methods and types that appear unused.

This includes methods you call from JavaScript.

❌ Symptom

In Debug:

DotNet.invokeMethodAsync("MyApp", "OnMarkerClicked")

→ Works.

In Release with trimming:

→ No error.

→ Nothing happens.

→ The method was removed.

✔ Fix

Mark all JS‑callable .NET methods:

[JSInvokable]
public static void OnMarkerClicked(string id) { ... }

If you rely on reflection/dynamic serializers:

[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(MyDto))]
public void Serialize() { ... }

Or root the assembly:

<ItemGroup>
  <TrimmerRootAssembly Include="$(AssemblyName)" />
</ItemGroup>

2. External Libraries Load Faster in Production

JS bundles load faster after trimming + minification.

This reveals race conditions you never see locally.

Google Maps example:

In Debug:

Your script loads
Then Google Maps loads
Then you call AdvancedMarkerElement

In Release:

Your code runs before the Maps library exists
AdvancedMarkerElement is undefined
No errors from Google Maps (silent fail)

✔ Proper Fix (Google's recommended way)

Use importLibrary():

const mapsLib = await google.maps.importLibrary("maps");
const markerLib = await google.maps.importLibrary("marker");

This removes 100% of all race conditions.

3. JS Exceptions Are Hidden in Minified Release

Many JavaScript errors disappear after minification.

Especially inside Google Maps, Stripe, and other SDKs.

❌ Symptom

Everything “just stops working” — no console errors.

✔ Fix

Wrap interop calls in try/catch and surface errors to .NET:

export async function safe(fn, ...args) {
  try {
    return await fn(...args);
  } catch (e) {
    console.error("JS Error", e);
    throw e;
  }
}

Then call via:

await module.InvokeVoidAsync("safe", "setMarkers", items);

Now errors show up again.

4. JSON Serialization + Trimming = Missing Properties

If your DTOs are used dynamically — especially when loading external data (API → map markers) — trimming removes properties.

❌ Symptom

Objects arrive missing fields:

{ "lat": 0, "lng": 0 }

✔ Fix

Use PreserveReferencesHandling or DynamicDependency:

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicProperties)]
public class MarkerDto { ... }

Or root your shared models assembly.

5. External APIs Fail Only in Production

Google Maps, Stripe, Firebase, and many others check:

referrer domains
HTTPS
billing enabled
CORS
CSP rules

❌ Symptom

Everything works locally.

In prod — nothing loads.

✔ Fix Checklist

Allow these in production:

https://*.yourdomain.com/*
HTTPS only
CSP rules:

script-src maps.googleapis.com maps.gstatic.com 'self'
connect-src https://maps.googleapis.com

And verify billing + quotas.

6. “Silent Failures” From Adblockers and Privacy Extensions

In production environments, up to 40% of users run blockers that:

Block Maps scripts
Block geolocation
Block telemetry endpoints
Block Blazor's own _framework files (rare, but happens)

✔ Fix

Detect Maps load failure:

try {
  await google.maps.importLibrary("maps");
} catch (e) {
  showFallbackMap();
}

7. Hosting Pitfalls: Caching, Routing & Fingerprints

Typical issues:

CDN caching old versions of _framework/*.wasm
index.html cached too long
404s for lazy-loaded modules
Wrong MIME types for .dll and .wasm

✔ Fix

Add correct headers:

_cache-control: no-store for index.html
_cache-control: immutable for .dll, .wasm

And SPA fallback:

Rewrite ^/(.*)$ /index.html

8. Google Maps Case Study: What Was Actually Broken

A real-world case:

❌ Local debug:

Everything works.

❌ Production:

No map
No markers
No console errors
Nothing loads

Root Causes

Google Maps library loaded after app code
AdvancedMarkerElement accessed before marker library existed
DTO properties trimmed away
JS → .NET callbacks trimmed
CSP blocked maps scripts

✔ Final Working Solution

Inline Google Maps bootstrap loader
Lazy load via importLibrary()
All JS-callable .NET methods marked [JSInvokable]
Assembly rooted
CSP + referrer config fixed
Wrapped all JS interop in safe error forwarding

→ 100% stable in production.

Final Thoughts

Blazor WebAssembly is powerful — but once you publish with trimming, you are no longer running the same application as in Debug.

If something works locally but breaks silently in prod, it is almost always one of these:

Trimming removed something
JS executed too early
External SDK blocked
CSP/Referrer issues
DTOs missing due to ILLink
JS exceptions swallowed by minification

Use the patterns in this post, and your WASM apps will behave identically in Debug and Release.

Forem: Jan Hjørdie

Integrating Campaign Monitor Smart Emails (Transactional) — Minimal Guide

Authentication

Key implementation notes

Smart Email payload shape

Sending strategy implemented in CampaignMonitorService

Robust subscriber parsing

HTML generation for list data

Batching, throttling and retries

Logging and diagnostics

Example (C#) — sanitized

Testing helpers

Real Blazor WebAssembly Production Pitfalls

Real Blazor WebAssembly Production Pitfalls

(With Google Maps as a Case Study)

1. Trimming Removes .NET Methods Used by JS Interop

❌ Symptom

✔ Fix

2. External Libraries Load Faster in Production

Google Maps example:

✔ Proper Fix (Google's recommended way)

3. JS Exceptions Are Hidden in Minified Release

❌ Symptom

✔ Fix

4. JSON Serialization + Trimming = Missing Properties

❌ Symptom

✔ Fix

5. External APIs Fail Only in Production

❌ Symptom

✔ Fix Checklist

6. “Silent Failures” From Adblockers and Privacy Extensions

✔ Fix

7. Hosting Pitfalls: Caching, Routing & Fingerprints

Typical issues:

✔ Fix

8. Google Maps Case Study: What Was Actually Broken

❌ Local debug:

❌ Production:

Root Causes

✔ Final Working Solution

Final Thoughts

Sending strategy implemented in `CampaignMonitorService`