Message Tags
Label any send with your own name and value pairs, then filter your logs on them and read them back from every webhook payload.
A tag is a name and a value you choose. Attach an array of them to a send, and the pair travels through delivery and back out on every event the message produces.
campaign and spring-sale mean whatever they mean to you, and nothing on our side depends on the words.
Both transports, identical shape
Over REST that is a tags array on the send request, and over SMTP the same JSON array in an X-Mailkube-Tags header. Validation is the same either way.
Tags then show up in three places. The log entry carries them, and narrowing your history to one campaign becomes a filter rather than an export. The dashboard’s Tags Performance view groups sending volume by tag. The data block of every email.* webhook returns them, and a receiver can route on tenant without a lookup.
What the validator enforces
name and value take ASCII letters, digits, underscore and hyphen. name is required, unique within a send, and capped at 16 characters. value may be blank and runs to 32. One message carries up to 20 tags, and the SMTP header has to parse as JSON under 16 KB.
Break any of that and the send fails as a whole, as a validation_error over REST or a 5.6.0 reply over SMTP. Nothing is quietly dropped. A tag that vanished silently would leave a gap in exactly the reporting you added it for.
Attaching your first tags
- Add a
tagsarray to your send, each entry anameand avalue - Send over REST or SMTP as usual
- Filter your sending logs on any tag, and open the dashboard breakdown
- Read the tags back out of your webhook payloads
A tag value is stored in the clear, and the aggregate metrics leave it out. Keep personal data out of them: a tenant id, not a customer’s name.