## Inbox fields
### Header
Heading shown in bold at the top of the card. Use it for the summary: `New comment received`, `Your story has got 30 views`.
### Body
Body of the notification. This is where the content of your notification will be passed. Supports both **Markdown** and **HTML** syntax, so you can format text, add links, lists, tables, images, and more.
` | | Line break (multiple) | NA | `
` | | Link | `[link text](https://example.com)` | `link text` | | Image | `` | `
` |
| Unordered list | `- Item 1``- Item 2` | `
- Item 1
- Item 2
`2. Item 2` | `
- Item 1
- Item 2
This is a note` | **Table** In Markdown, separate the header row from the body with a row of dashes, and use pipes (`|`) to separate columns: ```markdown theme={"system"} | Order | Status | |---|---| | #1234 | Shipped | | #1235 | Delivered | ``` The equivalent in HTML: ```html theme={"system"}
| Order | Status |
|---|---|
| #1234 | Shipped |
| #1235 | Delivered |
### Subtext
Clickable footer line below the message. Use for secondary info like comment count, task ID, or timestamps.
### Action URL
URL the user is redirected to on card click. Toggle **Open in new tab** if needed.
### Action Buttons
Up to 2 buttons with text + URL. Use it for click actions like "View", "Approve", or other inline actions. You can use it to redirect users to a webpage or handle inline actions using [custom click handlers](https://github.com/suprsend/suprsend-react-inbox/blob/main/docs/customization.md#action-button-custom-click-handlers).
### Tags
Tags filter and organise notifications inside [multiple tabs](/docs/multi-tabs). You can filter tabs by tag, [notification category](/docs/notification-category), or read status — for example, show all `unread` notifications with the `mentions` tag in a "Mentions" tab.
### Pinned
Pinned notifications display with a `pinned` badge and stay at the top of the notification list until the user it expires or user archives them. Use it for notifications requiring immediate action - compliance tasks, plan renewals, or limited-time offers. Always combine with an expiry so stale pins don't persist indefinitely.
### Expiry
Expiry auto-deletes the notification once the set period elapses. It deletes the notification and not archive it. So, you won't be able to access these notifications in your store once they expire. You can configure it three ways:
* **Absolute**
Set a fixed date and time. The timestamp uses your local timezone.
* **Relative**
Set a duration relative to when the notification is sent — for example, `2 days 6 hours`.
* **Dynamic**
For expiry computed from your event or user data, use a Handlebars variable — for example, `{{expiry_time}}`. The value can be:
* An ISO-8601 timestamp (for example, `2024-03-02T20:34:07Z`) — must be in the future.
* A relative duration: an integer (seconds) or an interval string like `2d 6h 30m 0s`.
A few recommendations:
* Always add an expiry to **pinned notifications** so they don't stay on top forever.
* For time-sensitive notifications like flash sales or event reminders, use a dynamic expiry to auto-delete once the event time is reached.
* Avoid expiry on long-lived notifications users might reference later (product updates, blog posts).
* For everything else, set an expiry of 15 days or more to keep the inbox clean.
#### Show expiry to user
Enable this to display a countdown timer on the notification card. The timer shows in grey when more than 1 hour remains and turns red below 1 hour to drive urgency.
### Extra Data
A JSON field for passing custom key-value pairs alongside the notification. Use this for app-level metadata that your frontend can process — for example, deep link parameters, feature flags, or tracking IDs.
This is also useful when you're building a **custom notification card** that needs data the generic Inbox template fields don't cover. Pass that extra data here, and your frontend can read it from the notification payload to render the card exactly how you want.
## Add variables in template
You can add dynamic variables in any template field using [Handlebars](/docs/handlebars-helpers) syntax (`{{variable_name}}`). Variables are replaced with real data at the time of sending.
Use the **Variables** panel on the left to add sample data — this powers the live preview and lets you test the template. Once data is added there, typing `{` in any field shows auto-suggestions from your variables. Variables with missing data are highlighted in red, so you can spot gaps at a glance.
Fill in the following fields, then click **Send Test**:
| Field | Required | Description |
| --------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Channel | Yes | The channel to test. Defaults to **In-App Inbox**. |
| Recipient | Yes | The user who will receive the test notification. Pick an existing recipient by their `distinct_id` or `email`. |
| Notification Category | No | The [notification category](/docs/notification-category) to send under — for example, `Transactional`. This is used to apply user preferences in that category. |
| Tenant ID | No | The [tenant](/docs/tenants) to test with. Defaults to `default`. |
## Commit Changes
Click **Commit** in the top bar to publish the current draft as a new live version. Add an optional description for versioning. Once committed, every notification triggered after this point uses the new content.
This applies to already-running workflows too: the template version is resolved at the moment of delivery, not when the workflow starts. For example, if a workflow has a delay node and you commit a new template version before that delay finishes, the notification is sent with the latest version. Templates and workflows are versioned independently, so locking a workflow version does **not** lock its templates.
## Frequently asked questions