Sometimes your users may not be allowed to access a particular feature because they aren’t subscribed to a plan with that feature, or they have no further allowance of that feature remaining. You’re going to want to identify if they are allowed to use a feature in order to grant or block access.
You should implement this each time you create a feature within Kana to ensure your user’s don’t accidentally use the feature in question when they shouldn’t.

​
Prerequisites

You will need to ensure you have details on both:
  • The user who has used the feature
  • The feature which the user has used
If neither the user nor feature exist yet in Kana, then you should create these first: Create Users Create Features Once these are created, you will need to ensure you know the id of both.
Both theid for a User and a Feature are defined by you upon creation in Kana.You can find the identifiers for both in the Dashboard, or by using the features and users queries to pull all respective records and grab the id from the one you need.

​
Code Sample

The canusefeature-featureid SDK method will work no matter what type of feature is being used, with the returned access boolean being true when the user has access (for Binary features), has enough of a feature remaining to be used (for Consumable features), or has overage enabled (for Consumable features).
Will the access boolean consider if a user will be using more than one of a feature?No - for Consumable features, we will only return false only if there’s no more of the feature be used by a delta of 1. We will not consider any greater delta currently. If the delta you need to provide when recording usage of the feature is greater than 1, you will need to understand if the user can access the feature yourself by using the returnedConsumption object and calculating the amount remaining via the used and budget fields.

​
Basic

React
import { KanaUserClient } from "@usekana/client-kana-js";

const client = new KanaUserClient({
  apiKey: API_KEY, // Make sure this is your PUBLIC API Key
  userId: localStorage.getItem(user).id, // Assumes user is stored as user in localStorage
});

const { data, error } = await client.canUseFeature({ featureId: "api-calls" });
console.log(data);
console.log(error);

​
Example

React
import React from "react";
import "./App.css";
import { useEffect, useState } from "react";
import { KanaUserClient } from "@usekana/client-kana-js";

function App() {
  const [canUseFeature, setCanUseFeature] = useState(false);

  useEffect(() => {
    const fetchAccess = async () => {
      const kanaClient = new KanaUserClient({
        apiKey: { API_KEY }, // Make sure this is your PUBLIC API Key
        userId: localStorage.getItem(user).id, // Assumes user is stored as user in localStorage
      });

      const { data, error } = await kanaClient.canUseFeature({
        featureId: "api-calls",
      });
      if (error) {
        console.log(error);
      }
      if (data) {
        setCanUseFeature(data.access);
      }
    };

    fetchAccess();
  }, []);

  return (
    <main>
      <h1>Kana Block Feature Usage Example</h1>
      <button type="button" disabled={!canUseFeature}>
        {" "}
        Use Feature{" "}
      </button>
    </main>
  );
}

export default App;
Ensure the state is set before the feature is viewed or used. If you need to prevent someone from navigating to the page altogether, then we recommend redirecting server-side (see our Block Feature Access (Backend) guide for example code).

​
Next Steps

Congratulations 🎉 You’ve now successfully checked a users entitlement to a feature and blocked them from using the feature if they should have no access.
You should look to ensure this is setup for all your features and in all places where those features could be used by customers. For instance, if you had a messages feature, your users may be able to send messages via your UI and through an API call - both should block access when necessary. You may want to also implement something similar on the backend of your application for those actions which don’t touch the frontend, or for any redirects before page load that you may want to action. Block Feature Access (Frontend) If you haven’t yet recorded usage of your features when access is granted, we strongly recommend this as a next step. It’s a key requirement in order for us to understand a user’s entitlement towards a feature. Record Feature Usage