BACK TO CONNECTORS

Queue-it's Akamai Connector v5 uses Akamai EdgeWorkers to integrate an Akamai-protected web server with Queue-it.

This page is intended to give a high-level technical overview of the Akamai Connector v5. To prevent malicious actors from compromising the security of our customers' high-profile sales and registrations, we host our in-depth Connector documentation in private repositories for versions v4 and up.

If you need more detailed integration documentation than this page offers, connect with one of our technical experts who can understand your use case and determine the optimal setup for your tech stack.

• Request received
  • User request reaches the Queue-it Connector on your edge infrastructure.
• Connector evaluation
  • The Queue-it Connector checks:
    • Does the request target a protected path?
    • Does the visitor have a valid Queue-it token?
• Call to Queue-it for decision logic
  • If the request is protected and no valid token is present, the Connector calls Queue-it to determine if the visitor needs to be queued based on your Queue-it configuration (e.g. traffic levels are above your threshold, rules allowing certain users to bypass the queue, waiting room is active or idle, etc.)
• Redirect to Queue-it
  • If the visitor needs to be queued, they are redirected with an HTTP 302 to a waiting room on Queue-it’s infrastructure.
  • If the visitor does not need to be queued (e.g. in a 24/7 Protection setup with low inflow), they proceed directly to the protected page without the need for a 302 redirect.
• Access granted
  • When it’s their turn, they are redirected back to your site with another HTTP 302 and given a signed token. With the signed token, the visitor’s request proceeds to the protected part of your site, and they continue their user journey without queuing.

In Bring Your Own CDN (BYO CDN) deployments, Queue-it operates behind your Akamai CDN, allowing traffic to continue flowing through your existing CDN infrastructure, security controls, monitoring tools, and routing policies while benefiting from Queue-it's traffic orchestration capabilities. 

You can read more about the Connector flow for versions 5 and up on our blog, including user flow diagrams for when users pass without queuing and in cases of service disruptions.

To learn more about how Queue-it works, including waiting room types and when/where Queue-it protects your site, visit Queue-it for developers.

Below you can see a high-level overview of the integration via Akamai EdgeWorkers (starts at 4:06).

To integrate using the Queue-it Akamai Connector v5, you will need:

• An active Queue-it account
• An active Akamai account
• Queue-it admin available (Someone available with GO Queue-it Platform access and familiarity with GO account configuration settings.)
• Akamai admin available (Someone available with access to the customer Akamai account and familiarity with all existing Akamai environmental configurations like PM rules and variables and EdgeWorkers)
• Akamai v5 Connector Download Access (Akamai admin must have been provisioned with access to the secure Queue-it v5 Connector GitHub repository – not available for public access.)
• A non-production Akamai property that can be used for implementing and testing the new Queue-it connector.

Note that BYO CDN integrations require Queue-it’s White Label add-on and are only available on enterprise plans.

The Akamai v5 Connector consists of the following components:

1. Queue-it EdgeWorker – code provided by Queue-it that enables the waiting room protection
2. PM Variables – variables that hold key values used by the EdgeWorker.
3. PM Rules – rules that provide coarse scope definition for the EdgeWorker protection and optionally also assist with integration configuration updates.
4. Queue-it Integration Configuration – configuration information created in the GO Queue-it Platform and propagated to the Akamai environment to be leveraged by the Queue-it Connector. This configuration information provides finer definition of the protection scope.

Complete these steps in order for best results.

1. Configure waiting rooms, actions, and triggers in Queue-it
2. Create EdgeWorker
3. Add PM variables
4. Create PM rules

Waiting rooms and their protection scope are created and configured in the GO Queue-it Platform, and any server-side (KnownUser) configuration information must be propagated to the Akamai environment for real-time access by the Queue-it Connector. When an integration configuration is published in the GO Queue-it Platform, the configuration settings are packaged into a JSON file and made available for retrieval by the Akamai integration.

There are two options for configuration settings:

1. Manual (inline) - Manually updating integration config within EdgeWorker code
2. Auto-Pull (cache) - Dynamically download and cache integration config

It's recommended to implement these configuration update methods in sequence for best results.

1. Manual method - implement this method first and confirm new PM rules are activating Queue-it EdgeWorker
2. Auto-Pull method – upgrade to this method to eliminate the need to update Akamai when Queue-it integration configuration changes

Queue-it's actions and triggers framework gives you a high degree of flexibility in determining what aspects of your site are covered by the virtual waiting room (see How Queue-it Works).

You can also use Akamai Property Manager rules and EdgeWorker capabilities to control which requests are evaluated by Queue-it. For example, static assets such as images, stylesheets, and media files can bypass Queue-it protection while critical application paths remain protected.

This allows you to tailor protection to the specific business-critical experiences that matter most during periods of high demand.