Advanced - Entry Key Invalidation

Entry Key Invalidation allows you to selectively invalidate waiting keys and entry keys under specific conditions, ensuring visitors must re-queue even if they would normally be protected by Queue Position Retention or Entry Pass. With timer-based invalidation, you can choose to invalidate entry keys only or both entry keys and waiting keys through the user scope setting. This guide explains the invalidation mechanisms, use cases, and configuration options.

Overview

Entry Key Invalidation is a mechanism that invalidates keys to ensure visitors must obtain new keys and re-queue under specific business conditions. The invalidation target depends on the invalidation type and settings: URL-based invalidation invalidates entry keys only, while timer-based invalidation can invalidate entry keys only or both entry keys and waiting keys depending on the user scope setting. This feature works in conjunction with Queue Position Retention and Entry Pass to provide granular control over access patterns.

Why Invalidation is Needed

While Queue Position Retention and Entry Pass provide excellent user experience by protecting visitors from losing their position, there are business scenarios where you need to enforce re-queuing:

• Fair access control: Ensure all visitors re-queue for critical phases
• Load management: Control server load by invalidating passes at specific times
• URL-based restrictions: Prevent pass sharing across different service endpoints
• Event phase transitions: Enforce re-queuing when moving to different event phases

What Gets Invalidated

Entry Key Invalidation affects two types of keys:

1. Waiting Keys (used for queue positions):

• When invalidated: Queue Position Retention is bypassed
• Effect: Visitors lose their queue position and must start from the end of the queue, regardless of Queue Position Retention period
• Use case: Enforce fair re-queuing even when Queue Position Retention is enabled

2. Entry Keys (used for service entry):

• When invalidated: Entry Pass is bypassed
• Effect: Visitors must re-queue through the waiting room, regardless of Entry Pass validity period
• Use case: Force re-queuing for critical service phases or specific URLs

How It Works

Entry Key Invalidation operates on a simple principle: force key reissuance when invalidation conditions are met. This ensures visitors cannot rely on previously issued keys and must go through the waiting room again.

Technical Principle

Keys that meet the invalidation conditions will be forcibly invalidated, causing the system to issue a new key, regardless of Queue Position Retention periods or Entry Pass validity periods. The invalidation target depends on the invalidation type and settings:

• URL-based invalidation: Invalidates entry keys only for users who access the specific URL
• Timer-based invalidation: Works differently depending on the user scope setting:
  • Entered users only: Invalidates entry keys only for users who have entered the service (waiting keys of waiting users are not affected)
  • From waiting users: Invalidates entry keys of entered users and waiting keys of waiting users (waiting users must re-queue from the end)
• Waiting key invalidation: Even with Queue Position Retention enabled and regardless of the Queue Position Retention period, visitors who disconnect and reconnect will lose their previous queue position and start from the end
• Entry key invalidation: Even with Entry Pass enabled and within Entry Pass validity period, visitors must re-queue if invalidation conditions are met, regardless of the Entry Pass validity period

Entry Key Invalidation provides two types of invalidation conditions:

1. URL-Based Invalidation

Invalidate keys when visitors access specific URLs.

Use case example: Multi-page event with selective access control

Let's say you have a segmented event where:

• Trigger rule: /event/1, /event/2, /event/3 paths trigger waiting room
• Entry Pass: 1 hour validity period
• Business requirement: All event pages except /event/3 allow Entry Pass, but /event/3 should always require re-queuing

Scenario Timeline:

10:00 AM  Visitor enters /event/1, receives entry key
          → Entry Pass valid for 1 hour until 11:00 AM
          
10:15 AM  Visitor accesses /event/2
          → Entry Pass still valid
          → Direct entry without queue ✓
          
10:30 AM  Visitor accesses /event/3
          → URL-based invalidation triggered
          → Entry key invalidated
          → Must go through waiting room again ✗
          
10:31 AM  Visitor receives new entry key after waiting
          → Access granted to /event/3 ✓

Configuration:

Simply enter the full URL path (including protocol) of the service path you want to invalidate:

https://example.com/event/3

Technical details:

• Works with UTI (URL-Triggered Integration) environments
• Full path matching required (protocol + domain + path)
• Only one URL can be configured per segment
• Available only in Basic Control segments (not supported in Section Control segments)

2. Timer-Based Invalidation

Automatically invalidate keys issued before a specific point in time. The invalidation target is determined by the user scope setting.

Use case example: Event fairness during critical phases

Let's say you have an event where:

• Entry Pass: 1 hour validity period by default
• Multiple event pages (/event/1, /event/2, /event/3) allow free navigation within 1 hour
• Critical requirement: After 2:00 PM, all visitors must re-queue for event fairness

Scenario Timeline:

1:00 PM   Visitor enters /event/1, receives entry key
          → Entry Pass valid until 2:00 PM
          
1:30 PM   Visitor navigates to /event/2
          → Entry Pass still valid
          → Direct entry ✓
          
1:45 PM   Visitor navigates to /event/3
          → Entry Pass still valid
          → Direct entry ✓
          
2:00 PM   Timer-based invalidation triggers
          → Keys issued before the scheduled time are invalidated
          
2:05 PM   Visitor tries to access any event page
          → Key invalidated at 2:00 PM
          → Must go through waiting room again ✗

Configuration:

1. Invalidation Time (minimum: 1 minute resolution):

   Invalidation Time: 2:00 PM

2. User Scope:

   • Entered users only: Invalidates (reissues) entry keys for users who have entered the service. Waiting users are not affected.
   • From waiting users: Invalidates (reissues) entry keys of entered users and waiting keys of waiting users.

How it works:

• System checks when each key was issued against the configured invalidation time
• Keys issued before the invalidation time are invalidated according to the user scope setting (regardless of Queue Position Retention/Entry Pass validity periods)
• Keys issued after the invalidation time have normal behavior
• Entered users only selected: Only entry keys are invalidated, requiring re-entry through the waiting room. Waiting users' waiting keys are not affected.
• From waiting users selected: Both entry keys of entered users and waiting keys of waiting users are invalidated, requiring waiting users to re-queue from the end

Combined Invalidation

URL-based and Timer-based invalidation can be used together for complex access control scenarios:

Example: Event with both URL and time restrictions

Configuration:
- URL invalidation: https://example.com/event/critical-phase
- Timer invalidation: 2:00 PM

Behavior:
- Before 2:00 PM: Only /event/critical-phase requires re-queuing
- After 2:00 PM: All pages require re-queuing

Configuration

Default Behavior

URL-based and Timer-based invalidation are independent settings that can be enabled or disabled separately:

• URL-based invalidation OFF (default): No URL-based invalidation occurs
• Timer-based invalidation OFF (default): No timer-based invalidation occurs
• Both features can be enabled independently
• Keys remain valid according to their respective Entry Pass validity periods when invalidation is disabled

When enabled:

• Invalidation checks occur at each access attempt
• Keys that meet the enabled invalidation conditions are immediately invalidated
• New keys must be obtained through the waiting room

Configuration Steps

You can configure Entry Key Invalidation when creating or editing a Basic Control Segment:

1. Navigate to your segment's settings (creation or edit mode)
2. Go to Advanced Settings section
3. Enable invalidation methods (can enable both independently):
   • Enable/disable URL-based invalidation
   • Enable/disable Timer-based invalidation
4. Configure invalidation conditions:
   • URL-based: Add full URL when enabled
   • Timer-based: When enabled, configure the following settings:
     • Set invalidation time (minimum: 1 minute resolution)
     • Select user scope:
       • Entered users only: Invalidates entry keys only
       • From waiting users: Invalidates entry keys of entered users and waiting keys of waiting users
5. Save Configuration: Apply your settings

Segment Type Support

Basic Control segments:

• Both URL-based and Timer-based invalidation are available

Section Control segments:

• Only Timer-based invalidation is available
• URL-based invalidation is not supported (no UTI/Trigger rule support)

Best Practices

When to Use URL-Based Invalidation

Use URL-based invalidation when:

• Different pages require different access levels
• Some pages are more critical and require fresh queuing
• You want to prevent users from accessing certain pages even with Entry Pass
• Multi-page events with selective access control

Example scenarios:

• Live streaming events: Main page allows Entry Pass, Q&A page requires re-queuing
• Multi-phase sales: Browse allows Entry Pass, purchase page requires re-queuing
• Tiered access: Free content allows Entry Pass, premium content requires re-queuing

When to Use Timer-Based Invalidation

Use timer-based invalidation when:

• Fairness is critical at specific event times
• You need to control server load at scheduled intervals
• Event phases transition at fixed times
• You want to enforce periodic re-verification

User Scope Selection Guide:

• Entered users only: When you want only entered users to re-queue while preserving waiting users' queue positions
• From waiting users: When you want all users (including waiting users) to re-queue fairly at the scheduled time

Example scenarios:

• Live events: Force re-queuing at showtime (From waiting users recommended)
• Limited releases: Invalidate passes after initial rush period (Entered users only may be sufficient)
• Scheduled sales: Require fresh queuing for each sale phase (From waiting users recommended)
• Event transitions: Move from warmup to main event with re-queuing (From waiting users recommended)

Combining Both Methods

Complex event scenarios benefit from combined invalidation:

Event Structure:
- Warmup phase (10:00 AM - 11:00 AM): URL-based invalidation for premium content
- Main event (11:00 AM - 12:00 PM): Timer-based invalidation at 11:00 AM
- Q&A phase (12:00 PM - 1:00 PM): URL-based invalidation for Q&A URLs

Configuration:
- URL invalidation: 
  * https://example.com/event/premium
  * https://example.com/event/qa
- Timer invalidation: 11:00 AM

Precautions

Consider user experience:

• Too frequent invalidation can frustrate users
• Communicate invalidation timing to users when possible
• Balance fairness with usability

Monitor system load:

• Sudden influx of re-queuing users can create spikes
• Plan invalidation timing to avoid overload
• Consider traffic patterns before setting invalidation times

Test thoroughly:

• Verify invalidation triggers work as expected
• Test with Queue Position Retention and Entry Pass combinations
• Ensure users understand they need to re-queue

Interactions with Other Features

Queue Position Retention Interaction

When Queue Position Retention is enabled and Entry Key Invalidation is triggered:

• URL-based invalidation: Only entry keys are invalidated, so waiting keys are not affected. Waiting users' queue positions are maintained.
• Timer-based invalidation:
  • Entered users only: Only entry keys are invalidated (reissued), so waiting keys are not affected. Waiting users' queue positions are maintained.
  • From waiting users: Waiting keys are invalidated (reissued), causing users to lose their queue position and start from the end. Even if within Queue Position Retention period, key invalidation takes priority.
• New key issued: For invalidated keys, users receive new keys and join the queue from the back.

Priority: Invalidation > Queue Position Retention (only applies when waiting keys are invalidated)

Entry Pass Interaction

When Entry Pass is enabled and Entry Key Invalidation is triggered:

• Entry key is invalidated: User loses Entry Pass privileges
• Entry Pass validity period is bypassed: Even if within Entry Pass validity period, invalidation takes priority
• Re-queue required: User must go through waiting room again

Priority: Invalidation > Entry Pass

Combined Protection Scenarios

Scenario 1: URL invalidation during Entry Pass window

Entry Pass: 1 hour validity
URL invalidation: /critical-page
Timeline:
  10:00 AM → Entry Pass granted
  10:30 AM → Access /normal-page (Entry Pass valid)
  10:45 AM → Access /critical-page (URL invalidation triggers, re-queue required)

Scenario 2: Timer invalidation during Queue Position Retention period

Queue Position Retention period: 5 minutes
Timer invalidation: 10:28 AM
User scope: From waiting users
Timeline:
  10:25 AM → User disconnects (queue position #50 retained by Queue Position Retention)
  10:28 AM → Timer invalidation triggers (waiting key invalidated)
  10:29 AM → User reconnects (timer already triggered)
              → Must re-queue from end

Scenario 3: Timer invalidation - Entered users only

Timer invalidation: 2:00 PM
User scope: Entered users only
Timeline:
  1:30 PM → User A: Service entry completed (has entry key)
  1:45 PM → User B: Waiting (has waiting key, position #10)
  2:00 PM → Timer invalidation triggers
          → User A: Entry key invalidated (must wait for re-entry)
          → User B: Waiting key maintained (position #10 maintained)

Verification

You can verify Entry Key Invalidation functionality with a simple test:

Setup:

1. Enable Entry Pass with 30-minute validity period
2. Enable Entry Key Invalidation (URL or Timer based)
3. Configure invalidation condition

Test steps:

10:00 AM  Visitor enters service, receives entry key
          → Entry Pass valid until 10:30 AM
          
10:15 AM  Visitor accesses service
          → Entry Pass still valid
          → Direct entry ✓
          
10:20 AM  Invalidation condition met (URL accessed or timer triggered)
          → Entry key invalidated
          
10:25 AM  Visitor attempts service access
          → Entry key invalidated
          → Must go through waiting room again ✗
          → Re-queues, receives new entry key
          
10:26 AM  Visitor accesses service with new key
          → Direct entry ✓ (new Entry Pass issued)

What this proves:

• Invalidation takes priority over Entry Pass validity period
• Invalidated keys cannot be reused
• Users must obtain new keys through waiting room
• New Entry Pass is issued after successful re-queue

FAQ

Can I use invalidation without Queue Position Retention or Entry Pass?

Yes, invalidation is independent. However, invalidation has maximum impact when used with Queue Position Retention and Entry Pass, as it provides granular control over when to bypass these protections.

What happens if I trigger invalidation multiple times?

Invalidation is event-based: each time a key is checked and meets invalidation conditions, it gets invalidated. You can combine multiple invalidation conditions (URL + Timer) for complex scenarios.

Can I disable invalidation after enabling it?

Yes! Disabling Entry Key Invalidation is a real-time change that takes effect immediately. Keys that were invalidated remain invalid, but new keys issued after disabling invalidation will have normal behavior.

Does invalidation work with all integration types?

URL-based invalidation works with UTI (URL-Triggered Integration). Timer-based invalidation works with all integration types (UTI and CBI).

Can I invalidate waiting keys and entry keys separately?

With timer-based invalidation, you can choose through the user scope setting:

• Entered users only: Only entry keys are invalidated (reissued). Waiting users' waiting keys are not affected.
• From waiting users: Both entry keys of entered users and waiting keys of waiting users are invalidated (reissued).

URL-based invalidation invalidates entry keys only (entry keys of users who access the URL are invalidated).

For related configuration options, see Advanced Timing, Queue Position Retention, and Entry Pass documentation.