> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeotap.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Gateway
> Configure frequency capping policies to control how many messages a user receives within a given time window across all Journeys.
## Overview
Gateway is Zeotap CDP's frequency capping module, found under **Orchestrate**. It lets you create policies that control how many times a message can be sent to any single user within a given time window — across all message types or per channel.
* **Prevents message fatigue** and over-communication
* **Protects user experience** by enforcing consistent communication limits
* **Fine-grained control** for marketing and CRM teams over messaging egress
Gateway policies apply exclusively within **Journeys**. They are enforced at the point of sending to a destination and only apply to messaging destinations (Email, SMS, In-App Push, Web Push).
***
## Key Concepts
### Policy
A named configuration that defines one or more frequency rules. Each policy must have at least one rule and applies to all Journeys within your organisation.
### Frequency Rule
A single condition within a policy. It specifies:
* The **maximum number of messages** to send to a user
* The **channel type** the rule targets
* The **specific destination mappings** to include (for channel-specific rules)
* The **time window** (in days) over which the cap applies
### Message Categories
Messages are grouped into four categories:
* Email
* SMS
* In-App Push
* Web Push
### Policy Status
| Status | Description |
| -------- | -------------------------------------------------------------- |
| Enabled | Policy is active and enforced on all applicable Journey sends. |
| Disabled | Policy exists but is not enforced. No caps are applied. |
***
## How Gateway Works
### Enforcement Flow
When a Journey attempts to send a message to a user via a connected destination:
1. The system checks whether any **enabled** Gateway policy applies to that destination.
2. If a policy applies, it evaluates whether the user has already hit their frequency cap for the current time window.
3. If the cap has been reached, the **send is blocked** and the Journey logs an error for that user.
4. If the cap has not been reached, the message is sent and the counter is incremented.
### Counter Reset
* Counters reset at **00:00:00 UTC** based on the duration mentioned in the policy.
* Caps are based on **calendar days**, not rolling 24-hour windows.
### When a Policy is Created
The policy takes effect immediately but the first full enforcement window begins on the next calendar day.
To ensure correct policy behaviour, allow the first full calendar day to pass after creating or editing a policy before relying on the cap being fully enforced.
### When a Policy is Edited
* All counters are **reset immediately** upon saving.
* The edited policy behaves like a newly created policy — full enforcement begins from the next calendar day.
***
## Supported Destinations
Gateway policies can only be applied to destinations that trigger a message send.
| Destination | Action | Message Category |
| -------------------------- | ------------------------------------- | --------------------------------- |
| Emarsys | Send triggered event (Journeys) | Email |
| Optimizely Campaigns | Send attributes and identifiers | Email |
| Iterable: Campaign Trigger | Trigger Campaign | Email, SMS, In-App Push, Web Push |
| Elaine – Trigger Events | Send Events to Elaine | Email |
| WhatsApp | Send data to message template | In-App Push |
| Inxmail API: Journeys | Trigger Events in Inxmail Commerce | Email |
| SFMC Journey Builder | Stream Events to SFMC Journey Builder | Email |
Only destinations that trigger a messaging action are eligible for Gateway policies. Non-messaging destinations (e.g., data exports, audience sync) are not affected.
***
## Creating a Policy
Navigate to **Orchestrate > Gateway** and click **+ Create Policy**.
Enter a descriptive policy name for easy identification (e.g., "Email Daily Cap").
Each rule is expressed as:
> Send no more than **\[X]** **\[channel type]** **\[from mapping(s)]** to a user every **\[Y] Days**
| Field | Description | Options / Constraints |
| ------------ | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| Limit (X) | Maximum sends per user | Any positive integer |
| Channel Type | The messaging channel to cap | Messaging of any type, Email, SMS, In-App Push, Web Push |
| From Mapping | Specific destination(s) to apply the cap to. Only shown for specific channel types — not for "Messaging of any type". | Multi-select from configured destination mappings |
| Duration (Y) | The time window for the cap | 1–7 days (calendar days, resets at 00:00 UTC) |
Click **+ Add Rule** to add additional rules to the same policy. All rules are joined by **AND logic**. Each rule can be deleted individually using the trash icon.
Click **Create Policy**. The policy is saved with **Enabled** status by default and will be enforced from the next calendar day.
***
## Managing Policies
### Policy List
The Gateway home screen displays all policies for your organisation with the following columns:
| Column | Description |
| --------------- | ----------------------------------------- |
| ID | Unique system-assigned policy identifier. |
| Policy Name | The name you provided during creation. |
| Status | Enabled or Disabled. |
| Last Updated On | Timestamp of the most recent edit. |
| Last Updated By | User who last modified the policy. |
| Created On | Timestamp of policy creation. |
| Created By | User who created the policy. |
* Use the **search bar** to filter policies by name.
* Click any **column header** to sort. Default sort is by Created On (descending).
### Actions
Click the three-dot menu on any policy row to access:
| Action | Description |
| ------- | ----------------------------------------------------------------------------------- |
| View | Open a read-only view of the policy details. |
| Edit | Modify the policy name or rules. All counters reset on save. |
| Disable | Pause enforcement without deleting the policy. Toggle back to Enable to reactivate. |
| Delete | Permanently remove the policy. This action cannot be undone. |
***
## Gateway & Journeys
Gateway is enforced automatically at the Journeys send layer. There is no additional configuration needed within a Journey — once a policy is enabled, it applies to all qualifying sends.
### What Happens When a User is Blocked
* The message send is **blocked** for that user.
* The Journey records an **error** against that user in the execution log, indicating the send was blocked by a Gateway policy.
* Other users in the same Journey who have not hit their cap continue to receive messages normally.
* The blocked user will be eligible again once the counter resets at **00:00 UTC** based on the policy duration.
### Which Journeys are Affected
* All **published** Journeys in your organisation that send via a supported destination are subject to active Gateway policies.
* Journeys using non-messaging destinations are unaffected.
***
## User Roles & Permissions
Access to Gateway is controlled through Zeotap CDP's role-based access control (RBAC) system.
### Access Levels
| Access Level | Permissions |
| ------------ | --------------------------------------- |
| Editor | View, Create, Edit, and Delete policies |
| Viewer | View policies only |
### Role to Access Mapping
| Role | Gateway Access |
| -------------------- | -------------- |
| CDP Admin | Editor |
| CDP Manager | Editor |
| Destination Admin | Editor |
| Integrations Manager | Editor |
| Integrations Admin | Editor |
| Campaign Admin | Viewer |
| CDP Viewer | Viewer |
| Destination Viewer | Viewer |
| Campaign Viewer | Viewer |
| Integrations Viewer | Viewer |
| Campaign Manager | Viewer |
***
## Example Use Cases
### Global daily cap across all channels
A retailer wants to ensure no user receives more than 3 messages per day regardless of channel.
* **Channel type:** Messaging of any type
* **Limit:** 3 per 1 Day
* **Result:** Once a user has received 3 messages (across any channel), further sends are blocked for the rest of that calendar day.
### Email-only cap for a specific tool
A CRM team wants to limit Iterable email sends to 1 per day per user, while keeping SMS unrestricted.
* **Channel type:** Email
* **From mapping:** Iterable: Campaign Trigger
* **Limit:** 1 per 1 Day
* **Result:** Only Iterable email sends are counted. SMS, In-App, and Web Push sends via Iterable are unaffected.
### Multi-rule policy with AND logic
A team wants to cap both email and SMS independently on the same day.
* **Rule 1:** Send no more than 2 Email to a user every 1 Day
* **Rule 2:** Send no more than 1 SMS to a user every 1 Day
* **Result:** A user receives a maximum of 2 emails and 1 SMS per day.
***
## Limits & Constraints
| Parameter | Limit |
| ------------------------- | ----------------------------------------------- |
| Maximum duration per rule | 7 calendar days |
| Minimum duration per rule | 1 calendar day |
| Time window type | Calendar days only (no rolling 24-hour windows) |
| Counter reset time | 00:00:00 UTC daily |
| Applicable products | Journeys only |
| Supported destinations | Messaging destinations only |
***
## Frequently Asked Questions
Yes. Once a policy is enabled, it applies to all qualifying sends from the next calendar day, regardless of when the Journey was created or published.
Full enforcement begins from the next calendar day (00:00 UTC). On the day of creation, behaviour may not be fully consistent until the following day.
All counters reset immediately. The policy behaves like it was freshly created — full enforcement resumes from the next calendar day. Users who were previously blocked may receive messages again until the new counters kick in.
Yes — but only using multiple rules with AND logic. Each rule can target a different channel/mapping combination.
Not currently. Gateway policies are enforced exclusively at the Journeys send layer.
All counters reset at 00:00:00 UTC regardless of the user's or organisation's local time zone.
It covers all four message categories — Email, SMS, In-App Push, and Web Push — across all supported destinations.
In the Journey execution log, you will see an error recorded against the affected user indicating the send was blocked by a Gateway policy.