Summary

Notification templates use bracketed replacement tokens ([user_login], [passwordcode], [order_id]). Tokens are:

1. Declared per-type in the mam_notification_list registry
2. Supplied at fire time in the message’s replacements array
3. Substituted by the channel sender into the per-channel template (subject, body)

Token declaration

In the type registry:

$data[] = array(
    'slug'         => 'mam-my-plugin-order_shipped',
    'replacements' => array( 'order_id', 'tracking_number', 'user_login' ),
    ...
);

Tokens are declared without brackets.

Token use in templates

In the per-channel template (admin-edited via Mobile App Manager → Notifications → Settings):

Your order [order_id] has shipped!
Track at: https://example.com/track/[tracking_number]
Thanks, [user_login].

Tokens appear with brackets.

Supplying values at fire time

do_action( 'mam_notification_send_message', array(
    'message_type' => 'mam-my-plugin-order_shipped',
    'recipient_id' => $user_id,
    'replacements' => array(
        'order_id'        => '42',
        'tracking_number' => 'ABC123',
        'user_login'      => $user->user_login,
    ),
) );

The dispatcher passes the replacements to each enabled channel sender; each sender substitutes into its template.

Built-in token sources

For the bundled user-roles types, the dispatcher auto-resolves WP-user tokens from the recipient:

You don’t need to supply these in replacements if they’re declared in the type’s replacements list — the dispatcher hydrates them from the recipient user record.

For custom tokens (order_id, tracking_number, etc.), you must supply them in replacements.

Common recipes

Pure custom tokens:

do_action( 'mam_notification_send_message', array(
    'message_type' => 'mam-my-plugin-order_shipped',
    'recipient_id' => $user_id,
    'replacements' => array(
        'order_id'        => '42',
        'tracking_number' => 'ABC123',
    ),
) );
// Built-in user_login, etc. auto-hydrated from $user_id

Subject-only override:

The subject template uses the same token system. Don’t try to override the subject inline at the call site — use the type’s templates and supply the tokens.

Multi-channel with shared tokens:

A single fire produces email + SMS + push. All three channels use the same tokens; only the templates differ.

Gotchas

• Tokens are case-sensitive. [user_login] and [User_Login] are different.
• Undefined tokens stay as [token_name] in the output — not removed, not blanked. This is intentional (you can spot bad templates) but ugly. Audit templates after registry changes.
• Token names must be distinct. A custom token that happens to share a name with a built-in ([user_login]) gets the supplied value, not the auto-hydrated one. Prefix custom tokens with your event name to avoid collisions: [order_user_login].
• No nested tokens. A token value of Hello [user_login] won’t have [user_login] further substituted.
• HTML-safe substitution is your responsibility. Tokens are inserted as-is; if a value contains HTML, it appears in the email body untouched.

Related articles

• Notifications overview
• Notification types registry
• Notification channels: email, SMS, push
• Hook: mam_notification_send_message
• Hook: mam_notification_list

Metadata