Why is it necessary?

CrowdHandler works by redirecting end-users attempting to hit a protected web page or application screen to a waiting room. If the API endpoints that drive the front end experience are discoverable, for example, if they are called clientside, tech savvy users, scalpers and/or bots may attempt to bypass the front end completely in order to get what they want directly via your API endpoints. 

Should I be concerned?

While not conclusive, you should consider protecting your API endpoints if one or more of the following criteria are met:

  • Your transactional API endpoints are discoverable.
  • You are selling popular products where demand is likely to outpace supply.
  • You have a tech savvy user base.
  • Your products are known to be targeted by resellers. 

Taking Action

Scenario 1 - API endpoint uses the same domain as the site you are protecting.

Example 

Protected Domain - https://tickets.example.com

API Endpoint - https://tickets.example.com/v1/api

Prerequisite

You should have already integrated your site with CrowdHandler using one of our CDN or Server Side integration options.

CrowdHandler Room Protection Options

All URLs

No further action required

URLs Matching Regular Expressions

  • The page(s) where end users add the in-demand product to the cart should be protected.
  • The API route that facilitates adding the in-demand product to the cart should be protected.

Considerations

My API URL routes are generic

Modify your API URL routes to contain the product ID or Slug as query string parameters.

https://tickets.example.com/v1/api/basket -> https://tickets.example.com/v1/api/basket?id=64398

This will result in CrowdHandler room matches. 

Prevent Spoofing

In your API, assert that the product ID or slug included in the API URL matches the product ID or slug in the payload. Without this additional layer of protection, the product ID or slug in the query string can be modified to bypass your CrowdHandler room configuration. 

Scenario 2 - API endpoint uses a different domain from the site you are protecting.

Example 

Protected Domain - https://tickets.example.com

API Endpoint - https://datasource.com/v1/api

CrowdHandler Room Configuration

  1. Configure your CrowdHandler rooms to protect the site domain (https://tickets.example.com), NOT the API domain.
  2. The page(s) where end users add the in-demand product to the cart should be protected.
  3. Room configuration should match URLs on your protected domain only.

Implementation Steps

Modify API requests Payload

Add two additional fields to your add to cart API route payload.
Key: sourceURL
Value: location.href (the URL of the protected page making the API call)
Key: chToken
Value: CrowdHandler token (retrieved from cookie or local storage, depending on integration type).

Validate the request server-side. 

const urlParts = new URL(params.sourceURL);
const token = params.chToken;

const crowdhandler = require('crowdhandler-sdk');

  const mockRequest = {
    getHost: () => urlParts.host,
    getPath: () => urlParts.pathname,
    getCookies: () => `crowdhandler=${token}`
  };

  const { gatekeeper } = crowdhandler.init({
    publicKey: 'your-public-key',
    request: mockRequest,
    response: {}, // Empty object is fine for validation only
  });

  const result = await gatekeeper.validateRequest();
  // ✅ This works!
  // result.promoted = true/false
  // Reject if false ❌
  // result.error = { message, statusCode, code } (if error occurred)