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:- 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:- The system checks whether any enabled Gateway policy applies to that destination.
- If a policy applies, it evaluates whether the user has already hit their frequency cap for the current time window.
- If the cap has been reached, the send is blocked and the Journey logs an error for that user.
- 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.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) | |
| Optimizely Campaigns | Send attributes and identifiers | |
| Iterable: Campaign Trigger | Trigger Campaign | Email, SMS, In-App Push, Web Push |
| Elaine – Trigger Events | Send Events to Elaine | |
| Send data to message template | In-App Push | |
| Inxmail API: Journeys | Trigger Events in Inxmail Commerce | |
| SFMC Journey Builder | Stream Events to SFMC Journey Builder |
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.Define a frequency rule
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) |
Add more rules (optional)
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.
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
Does a policy apply retroactively to Journeys that are already running?
Does a policy apply retroactively to Journeys that are already running?
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.
When does enforcement actually start after I create a policy?
When does enforcement actually start after I create a policy?
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.
What happens if I edit a policy mid-day?
What happens if I edit a policy mid-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.
Can I apply different caps to different destinations in one policy?
Can I apply different caps to different destinations in one policy?
Yes — but only using multiple rules with AND logic. Each rule can target a different channel/mapping combination.
Can I use Gateway outside of Journeys?
Can I use Gateway outside of Journeys?
Not currently. Gateway policies are enforced exclusively at the Journeys send layer.
What time zone is used for the reset?
What time zone is used for the reset?
All counters reset at 00:00:00 UTC regardless of the user’s or organisation’s local time zone.
What does 'Messaging of any type' cover?
What does 'Messaging of any type' cover?
It covers all four message categories — Email, SMS, In-App Push, and Web Push — across all supported destinations.
Where can I see if a user was blocked by a policy?
Where can I see if a user was blocked by a policy?
In the Journey execution log, you will see an error recorded against the affected user indicating the send was blocked by a Gateway policy.