🔒 Push Notification Limit Configuration

REL-IDverify provides a Push Notification Limit Configuration mechanism that allows enterprises to control the frequency of notifications sent to a user based on their past actions (e.g., frequent rejections or fraud reports). These rules help prevent misuse, over-notification, or automated rejection loops.

🧭 Purpose

To prevent spam or misuse, enterprises can configure restrictions on how often push notifications can be generated based on a user’s repeated negative actions (e.g., Reject, Fraud) over a defined time window.

⚙️ Configuration Parameters

Each limit rule contains the following properties:

⚠️

Action types are case-sensitive. "Reject" and "reject" will be treated as different.

🧪 Sample Configuration

"enterprise_id": "Ent1",
"limits": [
  { "window_type": "30:M", "limit": 3, "action_type": "Reject" }
]

The above rule will prevent further push notifications if a user performs the Reject action 3 times within 30 minutes. The limit resets after the window closes.

🔄 Window Logic

• A limiting window begins when a user performs the configured action_type.
• The window closes automatically after the specified time (e.g., 30 minutes).
• New notifications can be sent only after the window closes.

🔀 Multiple Conditions

"enterprise_id": "Ent2",
"limits": [
  { "window_type": "1:H", "limit": 1, "action_type": "Fraud" },
  { "window_type": "30:M", "limit": 3, "action_type": "Reject" }
]

If any condition is fulfilled (e.g., 1 Fraud in 1 hour or 3 Rejects in 30 minutes), the system will stop sending new push notifications for that user.

📌 Key Rules

• Existing notifications are not dismissed if limits are reached.
• Modifying limits does not reset open time windows.
• Limits are configured via the GM portal and require a restart of the REL-IDverify component to take effect.

📖 Examples

• Case 1: User clicks "Fraud" once – system halts all notifications for 1 hour.
• Case 2: User clicks "Reject" 3 times in 30 minutes – 4th notification is blocked until the window closes.
• Case 3: If both "Fraud" and "Reject" limits are active, the stricter condition takes precedence.

✅

Use this configuration to throttle high-risk interactions and control notification flow without interrupting valid user actions.