In this guide we will put the entitlement check inside a TypeScript publication action, before it records any work. You'll configure two plans, send direct HTTP requests for each customer, and verify both the denial and the successful publication.

I build Subscrio, the entitlement library used here. It resolves whether a customer has a feature; the application must use that answer before performing the operation.

Before you get started

The complete BracketCamp sample is in the public Subscrio samples repository. To run it, you'll need:

• Node.js and npm to install dependencies and run the TypeScript example.

• A local PostgreSQL server and a development role that can create databases. Each test run creates and removes its own temporary database.

• Git to clone the repository.

• The Subscrio npm package, which the sample's npm ci command installs along with its other pinned dependencies.

The snippets follow one program's main flow. The linked sample includes its imports, database setup, and test helpers; the excerpts are not separate runnable programs.

The request that bypasses the button

BracketCamp is a fictional app for tournament organizers. Organizers use it to track matches; its Broadcast plan also lets them publish a live bracket so spectators can follow results. The Club plan keeps tournaments private.

Suppose the Club screen hides Publish, but the publication handler accepts every request it receives. An organizer can still send the same HTTP request directly. The problem is where the decision happens: hiding the button has not protected the publication action.

We'll test a Club customer named local-club and a Broadcast customer named regional-open. A direct request from Club should return HTTP 403 and publish nothing. Broadcast should receive HTTP 201 and have its publication recorded. Blocking both requests would fail the product's promise too.

Make the publication rule available to the server

The live-brackets feature will answer one question: can this customer publish a bracket for spectators? It defaults to false, and only Broadcast grants it. The following setup connects that rule to the two customer subscriptions before we write the action that uses it.

Connect Subscrio to the sample database

The sample calls isolatedDatabase, a helper defined in src/database.ts, to create a temporary PostgreSQL database. Its returned db.connectionString is passed to Subscrio. installSchema creates the tables that will hold the catalog and subscriptions.

const app = new Subscrio({ database: { connectionString: db.connectionString } });
await app.installSchema();

Register the tournament app

Create the bracketcamp product to group this app's plans and features.

await app.products.createProduct({ key: 'bracketcamp', displayName: 'BracketCamp' });

Define permission to publish a live bracket

A toggle represents this yes-or-no capability. The default "false" means a customer needs a qualifying subscription before publishing. Feature values are strings in the catalog API.

await app.features.createFeature({
  key: 'live-brackets',
  displayName: 'live-brackets',
  valueType: 'toggle',
  defaultValue: 'false',
});

Make the feature part of BracketCamp

Associate live-brackets with the product so its plans can assign a value.

await app.products.associateFeature('bracketcamp', 'live-brackets');

Create the private and public offerings

Club provides private tournament management. Broadcast includes publication for spectators. Create each plan under the same product.

for (const key of ['club', 'broadcast'])
  await app.plans.createPlan({ key, productKey: 'bracketcamp', displayName: key });

Allow publication only on Broadcast

Translate the commercial rule into feature values. Both subscriptions can use the product, but only Broadcast enables live-brackets.

await app.plans.setFeatureValue('club', 'live-brackets', 'false');
await app.plans.setFeatureValue('broadcast', 'live-brackets', 'true');

Add monthly subscription options

Each subscription must reference a billing cycle belonging to a plan. These monthly records provide that link; creating them does not collect payment.

for (const planKey of ['club', 'broadcast'])
  await app.billingCycles.createBillingCycle({
    key: planKey + '-monthly',
    planKey,
    displayName: 'Monthly',
    durationUnit: 'months',
    durationValue: 1,
  });

Create the two tournament customers

Register the tournament businesses separately so we can prove that the handler treats their subscriptions differently.

await app.customers.createCustomer({ key: 'local-club' });
await app.customers.createCustomer({ key: 'regional-open' });

Connect each customer to the plan they bought

club-agreement connects local-club to club-monthly; broadcast-agreement connects regional-open to broadcast-monthly. The publication action will receive the customer key and let Subscrio resolve the feature through this relationship.

await app.subscriptions.createSubscription({
  key: 'club-agreement',
  customerKey: 'local-club',
  billingCycleKey: 'club-monthly',
});
await app.subscriptions.createSubscription({
  key: 'broadcast-agreement',
  customerKey: 'regional-open',
  billingCycleKey: 'broadcast-monthly',
});

Check access before recording a publication

Now place the decision inside the action reached by the HTTP handler. publish is our application function. isEnabledForCustomer is the Subscrio API: it returns whether this customer has live-brackets in bracketcamp.

A false result returns a 403 response before the application records a publication. A true result records the customer and returns 201. The published array is a stand-in for accepted work so we can prove the denied request had no effect.

const published: string[] = [];
async function publish(customerKey: string) {
  const allowed = await app.featureChecker.isEnabledForCustomer(
    customerKey,
    'bracketcamp',
    'live-brackets',
  );
  if (!allowed) return { status: 403, body: { error: 'live_brackets_not_included' } };
  published.push(customerKey);
  return { status: 201, body: { status: 'published' } };
}

A production handler would create the actual bracket publication after the same check. It must also establish which customer the authenticated organizer represents; the test routes below use fixed customer keys only to exercise the entitlement decision.

Send requests that never touch the screen

The sample's replayPublicationRequests helper starts a temporary HTTP server on loopback, sends both requests with Node's fetch, verifies their status and JSON responses, and closes the server. It is test code in src/http-check.ts, not a Subscrio API. No request body or authentication header is needed for these fixed local test routes.

In the two calls below, baseUrl stands for the temporary server's address and port. They illustrate the requests the helper sends for each customer:

await fetch(baseUrl + '/customers/local-club/public-bracket', { method: 'POST' });
await fetch(baseUrl + '/customers/regional-open/public-bracket', { method: 'POST' });

The main program passes our publication function to that helper. Node's built-in assert.deepEqual then checks the accepted-work array, so a denied request cannot silently publish anyway.

await replayPublicationRequests(publish);
assert.deepEqual(published, ['regional-open']);

Captured responses:

local-club: HTTP 403 {"error":"live_brackets_not_included"}
regional-open: HTTP 201 {"status":"published"}

Club reached the server directly but could not publish. Broadcast succeeded, and published contains only regional-open. The restriction now holds even when a caller never opens the screen.

Run the complete example

The BracketCamp sample contains the complete program, imports, database helper, and assertions for the results shown here. Use Node.js and a local PostgreSQL server. Copy .env.example to .env and set DATABASE_URL to a development connection whose role can create databases. Keep that file private.

git clone https://github.com/subscrio/samples.git
cd samples/examples/server-side-feature-gating-typescript
cp .env.example .env
# Set DATABASE_URL in .env before continuing.
npm ci
npm test

Each run creates its own disposable database and removes it afterward. The snippets above follow the program's main flow; the database helper and final assertions live in the linked source. The assertions fail the run if the observed results differ from the expected customer behavior.

AI tools assisted with drafting and editing this article. The sample code and its expected behavior were checked separately through executable tests.