Actions

Actions automate communications in your workspace. Each action is either an email or a webhook — you define what triggers it, who receives it (or which URL it calls), and what content or payload to include. Instead of manually sending confirmation emails, payment reminders, or notifying external systems, actions handle these automatically whenever their conditions are met.

How It Works

Each action pairs a delivery method (email or webhook) with one or more triggers. When a trigger fires — whether from a system event, a schedule, or a manual click — Itsy evaluates any conditions you have set. If the conditions pass, the action executes: for email actions the message is rendered with order data and sent to the configured recipients; for webhook actions a JSON payload is dispatched to the configured URL. In both cases the delivery is tracked.

Key Concepts

Action Type

Every action has a type that determines how it delivers its message:

You choose the type when you create the action. Email actions and webhook actions share the same trigger system — the difference is only in how they deliver.

Action Properties

Both action types share these core properties:

Email-specific properties:

Webhook-specific properties:

Trigger Types

Each action can have multiple triggers. There are three types:

An action can have any combination of triggers — for example, you might have an action that fires both on the "Order Confirmed" event and can also be triggered manually from the order menu.

Available Events

Event triggers respond to 17 different system events:

Manual Trigger Placements

When you create a manual trigger, you choose where the trigger button appears in the admin interface:

Trigger Conditions

Conditions let you control exactly when a trigger fires. Each condition checks an order property against a value using a comparison operator.

Condition fields:

Comparison operators:

For date conditions, the value represents a number of days relative to today. For example, setting "Start Date is equal to -7" matches orders whose trip starts 7 days from now.

All conditions on a trigger must be satisfied for the trigger to fire (they are combined with AND logic).

Email Recipients

You can also add CC and BCC recipients to any action.

Email Content

The email body is built with a rich text editor that supports headings, paragraphs, bold, and italic formatting. You can insert special content blocks that are automatically populated with order data. Use the Insert Block dropdown in the editor toolbar to add them.

Information blocks:

Financial blocks:

Link blocks:

Special blocks:

You can also use inline template variables in both the subject line and body. These are replaced with real values when the action is delivered.

Order variables:

Client variables:

Workspace and sender variables:

Invoice variables (require invoice context):

Payment variables (require payment context):

In the email body, money values are displayed with the workspace currency prefix (e.g. "USD 1,500.00"). In the subject line, money values appear as raw numbers so you can format them inline.

Emails are rendered in the workspace's configured language (English or Icelandic).

Email Attachments

You can attach files to action emails:

Webhook Actions

Webhook actions let you notify external systems when events happen in your workspace. Instead of composing an email, Itsy sends a JSON payload to the URL you configure.

Payload Structure

Every webhook delivery includes a standard envelope with context about the event:

{
  "version": "v1",
  "event": "OrderConfirmed",
  "eventId": 3,
  "actionId": "...",
  "actionCode": "...",
  "actionName": "...",
  "deliveryId": "...",
  "workspaceId": "...",
  "timestamp": "2026-04-26T12:00:00Z",
  "context": {
    "order": { ... }
  }
}

The context object varies by event type. For payment events it includes a payment object alongside the order. For invoice events it includes an invoice object. For all other events, the context contains the full order snapshot.

Webhook payloads are designed to be self-contained — the order snapshot includes bookings, participants, payments, invoices, client details, and external references so receivers do not need to call back to Itsy for additional data.

Security Headers

Every webhook request includes these headers automatically:

To verify a webhook, compute the HMAC-SHA256 of the raw request body using your shared secret and compare it to the value in X-Itsy-Signature.

Retry Logic

When a webhook delivery fails (non-2xx HTTP status or network error), Itsy retries automatically with increasing delays:

Retries continue until the request succeeds or the maximum number of attempts is reached (configurable per action, default 5). A background job checks for due retries every minute. Each retry attempt and its outcome are logged in the delivery's event history.

URL Requirements

Webhook URLs must use HTTPS and resolve to a public IP address. Itsy rejects URLs that point to private, loopback, or link-local addresses to prevent internal network access.

Managed Actions

Itsy provides pre-built managed actions for essential workspace operations. These handle common scenarios that every workspace needs:

• Order Overview — Sends the order summary document to the customer
• Payment Receipt — Sends after payment validation
• Payment Reminder — Runs on a daily schedule, sending reminders to customers with outstanding balances
• Supplier Report — Delivers supplier activity reports
• Gift Certificate Purchase — Sends the certificate PDF to the purchaser after payment
• Trip Email — Sends trip-related communications to participants

Managed actions differ from regular actions in important ways:

• You cannot delete them
• You cannot change the name, code, recipient type, or attachments
• You can customize the email subject, body, sender details, CC/BCC, and active status

Action Templates

When creating a new action, you can start from a pre-built template instead of building from scratch:

Templates save time by setting up the trigger, conditions, and a starting configuration automatically.

Delivery Tracking

After an action sends a message, Itsy tracks its journey:

Email deliveries:

Each email delivery records the sender address, recipient address, timestamps, and any error details.

Webhook deliveries:

Webhook deliveries track the HTTP status code, number of attempts, next retry time (if a retry is scheduled), and a snippet of the response body. Each attempt is logged as a separate event, so you can see the full retry history.

All deliveries — both email and webhook — are logged on the order's timeline for audit purposes.

Deliveries Report

The deliveries report gives you a workspace-wide view of all action deliveries (email and webhook) across all actions. You can filter by:

• Specific actions — View deliveries for one or more actions
• Date range — Filter to a specific time period

The report shows up to 1,000 delivery records, sorted by most recent first.

Common Tasks

Creating a New Email Action

1. Navigate to the Actions section
2. Click Add
3. Choose a template (Blank, Order Confirmation, Payment Confirmation, or Payment Reminder)
4. Enter the action name and code
5. Configure the email subject, sender, and recipient
6. Build the email content using the rich text editor and insert content blocks as needed
7. Select any attachments to include
8. Add triggers to control when the action fires
9. Activate the action

Creating a Webhook Action

1. Navigate to the Actions section
2. Click Add
3. Choose the Webhook Blank template
4. Enter the action name and code
5. Set the Webhook URL (must be HTTPS)
6. Configure a Secret for payload signing (required for all webhook actions)
7. Choose the HTTP Method (POST or PUT)
8. Add any Custom Headers the receiving system requires
9. Set the Max Retry Attempts (default: 5)
10. Add triggers to control when the action fires
11. Activate the action

Adding Triggers to an Action

1. Open an action and go to the Triggers tab
2. Enable the trigger type you want:
   • For Manual, choose where the button appears (Order Item Overview, Order Top Menu, Invoice List Menu, or Payment Reminder Dialog)
   • For Schedule, the action runs daily at 02:00
   • For Event, select the specific event to listen for
3. Optionally add conditions to filter when the trigger fires
4. Save your changes

Setting Up Payment Reminders

1. Create an action using the Payment Reminder template
2. The template automatically sets up:
   • A daily schedule trigger
   • Conditions: balance is larger than 0, status is not Draft, status is not Cancelled, and the order is not already fully paid
3. Customize the email subject and body
4. Set the recipient to Order Client
5. Activate the action

Running a Manual Action

1. Open an order
2. Depending on the manual trigger's placement, find the action button in:
   • The quick actions on the order overview
   • The top menu of the order page
   • The invoice list actions menu
   • The payment reminder dialog
3. Click the action to execute it immediately (sending the email or firing the webhook, depending on the action type)

Reviewing Delivery History

1. To see deliveries for a specific action: open the action and go to the Deliveries tab
2. To see all deliveries across your workspace: go to the Deliveries report under Actions
3. Filter by action or date range as needed
4. Click on a delivery to see its full event log. For email deliveries this includes events such as submitted, delivered, opened, and bounced; for webhook deliveries it includes submitted, individual attempt results, retry-scheduled events, and the final outcome.

Customizing a Managed Action

1. Go to Settings and find Managed Emails
2. Select the managed action to customize (Order Overview, Payment Receipt, Payment Reminder, Supplier Report, Gift Certificate Purchase, or Trip Email)
3. Edit the email subject and body
4. Update sender details and CC/BCC if needed
5. Save your changes

How It Connects

• Orders — Most action triggers are based on order events. Deliveries are logged on the order timeline and can be viewed per client.
• Groups — Group message events can trigger notifications. The Group Contact recipient type sends to the group's contact person.
• Gift Certificates — Gift certificate creation can trigger delivery emails.
• Clients — Corporate clients can have contacts with specific notification preferences (invoices, payment receipts, order confirmations), and actions route emails to the appropriate contacts automatically.
• Segments — Actions can be targeted to specific customer segments, ensuring the right audience receives each communication.

Segment Targeting

Actions can be restricted to specific customer segments. When you configure an action, you can select one or more segments from the Segments field on the action overview. If no segments are selected, the action applies to all customers. When segments are selected, the action only triggers for orders belonging to customers in those segments.

This lets you create targeted communications — for example, a VIP welcome email that only goes to customers in your premium segment, or a local-language reminder for a specific market.

Coverage View

The Coverage page under Actions provides a matrix view of your automation setup. It shows which actions are configured for each combination of trigger event and customer segment.

• Rows represent trigger events — order lifecycle events, payment events, notification events, invoice events, group message events, gift certificate events, and scheduled triggers
• Columns represent your customer segments, each shown with its color indicator

Each cell lists the actions configured for that event-segment combination. Cells with no actions display a warning icon, helping you spot gaps in your automation coverage — for example, a segment that has no payment confirmation email configured.

Reading the Matrix

• Click any action name to navigate directly to that action's overview page for editing
• Expand a row to see the trigger conditions configured on each action (the field, comparison operator, and value)
• Inactive actions are marked with an "Inactive" badge so you can distinguish them from active ones
• Actions inherit their assigned color for visual consistency with the rest of the interface