This is page 2 of 7. Use http://codebase.md/bucketco/docs/type-check-failed.png%20%22Type%20check%20failed%22?lines=true&page={x} to view the full context.
# Directory Structure
```
├── .gitbook
│ ├── assets
│ │ ├── 03642c5-dwFrame_201 (1).png
│ │ ├── 03642c5-dwFrame_201.png
│ │ ├── 1753259671871 (1).jpeg
│ │ ├── 1a0b50d-image.png
│ │ ├── 1a439d9-image.png
│ │ ├── 2506596-Customized_Widgets.png
│ │ ├── 342658e-image.png
│ │ ├── 4017197-image.png
│ │ ├── 43e55f0-image.png
│ │ ├── 4783e3f-image.png
│ │ ├── 5b0ce63-image (1).png
│ │ ├── 5b0ce63-image.png
│ │ ├── 630b5e9-image.png
│ │ ├── 8bf8a6e-Frame_201.png
│ │ ├── 9efd67c-image.png
│ │ ├── aa37226-image.png
│ │ ├── Access (1) (1).png
│ │ ├── Access (1).png
│ │ ├── Access (2).png
│ │ ├── Access.png
│ │ ├── Adding features to a feature view-min.png
│ │ ├── Adopted-min.png
│ │ ├── Adoption strategy V2-min.png
│ │ ├── Adoption strategy-min.png
│ │ ├── Advanced targeting rules V2-min.png
│ │ ├── Advanced targeting rules v3-min.png
│ │ ├── Advanced targeting rules-min.png
│ │ ├── aecc6f2-image.png
│ │ ├── amplitude.svg
│ │ ├── An example targeting configuration with two rules.-min.png
│ │ ├── api.svg
│ │ ├── App Settings-min.png
│ │ ├── Automated feedback surveys settings v3-min.png
│ │ ├── Automated feedback surveys settings-min.png
│ │ ├── Automated feedback surveys-min.png
│ │ ├── aws-s3.svg
│ │ ├── be124cd-dwdwFrame_201 (1).png
│ │ ├── be124cd-dwdwFrame_201.png
│ │ ├── ccc4f9e-image.png
│ │ ├── CleanShot 2024-06-11 at 8 [email protected]
│ │ ├── CleanShot 2024-11-22 at 8 [email protected]
│ │ ├── CleanShot 2024-11-22 at 8 [email protected]
│ │ ├── CleanShot 2024-11-25 at 9 [email protected]
│ │ ├── CleanShot 2024-11-25 at 9 [email protected]
│ │ ├── CleanShot 2024-11-25 at 9 [email protected]
│ │ ├── CleanShot 2024-11-27 at 10 [email protected]
│ │ ├── CleanShot 2024-11-27 at 10 [email protected]
│ │ ├── CleanShot 2024-11-27 at 10 [email protected]
│ │ ├── CleanShot 2024-11-27 at 10 [email protected]
│ │ ├── CleanShot 2025-01-07 at 1 [email protected]
│ │ ├── CleanShot 2025-01-07 at 1 [email protected]
│ │ ├── CleanShot 2025-01-07 at 1 [email protected]
│ │ ├── CleanShot 2025-01-07 at 12 [email protected]
│ │ ├── CleanShot 2025-01-07 at 12 .39.12@2x (1).png
│ │ ├── CleanShot 2025-01-07 at 12 [email protected]
│ │ ├── CleanShot 2025-01-09 at 10 [email protected]
│ │ ├── CleanShot 2025-01-09 at 11 .11.54@2x (1).png
│ │ ├── CleanShot 2025-01-09 at 11 [email protected]
│ │ ├── CleanShot 2025-01-09 at 9 [email protected]
│ │ ├── CleanShot 2025-01-23 at 1 [email protected]
│ │ ├── CleanShot 2025-01-23 at 1 [email protected]
│ │ ├── CleanShot 2025-01-23 at 1 [email protected]
│ │ ├── CleanShot 2025-01-23 at 2 [email protected]
│ │ ├── CleanShot 2025-05-09 at 1 [email protected]
│ │ ├── CleanShot 2025-10-09 at 10 [email protected]
│ │ ├── Companies Tab-min.png
│ │ ├── Companies-min.png
│ │ ├── company example v2-min (1).png
│ │ ├── company example v2-min.png
│ │ ├── company example v3-min.png
│ │ ├── Company segment filters-min.png
│ │ ├── Create a new environment-min.png
│ │ ├── Creating and managing apps-min.png
│ │ ├── cursor-mcp-demo_h264.mp4
│ │ ├── datadog.svg
│ │ ├── Debugger-min (1).png
│ │ ├── Debugger-min (2).png
│ │ ├── Debugger-min.png
│ │ ├── Enabling Feedback Surveys-min.png
│ │ ├── Environments Page V2-min.png
│ │ ├── Environments Switcher-min.png
│ │ ├── Environments-min.png
│ │ ├── Evaluate Feature.png
│ │ ├── example 1 (1).png
│ │ ├── example 1.png
│ │ ├── example 2 (1).png
│ │ ├── example 2.png
│ │ ├── ezgif-242d06617aea38.gif
│ │ ├── Feature Tab-min.png
│ │ ├── Feature targeting rules example v2-min.png
│ │ ├── Feature targeting rules example V2-min.png
│ │ ├── Feature targeting rules example v3-min.png
│ │ ├── Feature targeting rules example-min.png
│ │ ├── Feature targeting rules UI V2-min.png
│ │ ├── Feature targeting rules UI v3-min.png
│ │ ├── Feature targeting rules UI-min.png
│ │ ├── Feature usage configuration-v2-min.png
│ │ ├── Feature view.png
│ │ ├── feature-flag-list-rum-event.d9c1c876a34458edc70d1317efaec05b.png.avif
│ │ ├── Feature-targeting-rules-v2-min.png
│ │ ├── Features Page V2-min (1).png
│ │ ├── Features Page V2-min.png
│ │ ├── Features Page-min.png
│ │ ├── Features-min.png
│ │ ├── Feedback Tab V2-min.png
│ │ ├── Feedback-min.png
│ │ ├── Getting started-min.png
│ │ ├── gitbook-logo.svg
│ │ ├── github-logo.svg
│ │ ├── Global settings - Feature views-min.png
│ │ ├── Global settings - Manual Targeting-min.png
│ │ ├── Global settings - Release Stages Editing V4-min.png
│ │ ├── Global settings - Release Stages-min.png
│ │ ├── Goal Form.png
│ │ ├── How to use release stages v2-min.png
│ │ ├── How to use release stages-min (1).png
│ │ ├── How to use release stages-min.png
│ │ ├── https___content.gitbook.com_content_pgXAy2Cgsm5pON9oJ06m_blobs_6wGbrQlJPE4JllBuIhla_image (1).png
│ │ ├── image (1) (1).png
│ │ ├── image (1) (2).png
│ │ ├── image (1).png
│ │ ├── image (10).png
│ │ ├── image (11).png
│ │ ├── image (12).png
│ │ ├── image (13).png
│ │ ├── image (14).png
│ │ ├── image (15).png
│ │ ├── image (16).png
│ │ ├── image (17).png
│ │ ├── image (18).png
│ │ ├── image (19).png
│ │ ├── image (2) (1).png
│ │ ├── image (2).png
│ │ ├── image (20).png
│ │ ├── image (21).png
│ │ ├── image (22).png
│ │ ├── image (23).png
│ │ ├── image (24).png
│ │ ├── image (25).png
│ │ ├── image (26).png
│ │ ├── image (27).png
│ │ ├── image (28).png
│ │ ├── image (29).png
│ │ ├── image (3).png
│ │ ├── image (30).png
│ │ ├── image (31).png
│ │ ├── image (32).png
│ │ ├── image (33).png
│ │ ├── image (4).png
│ │ ├── image (5).png
│ │ ├── image (6).png
│ │ ├── image (7).png
│ │ ├── image (8).png
│ │ ├── image (9).png
│ │ ├── image.png
│ │ ├── Iterate Feature V2.png
│ │ ├── LInear mention.mp4
│ │ ├── linear.svg
│ │ ├── mcp-remote-min.mp4
│ │ ├── mcp-remote.mp4
│ │ ├── mixpanel.svg
│ │ ├── Modifying or deleting an app-min.png
│ │ ├── Monitor (1) (1).png
│ │ ├── Monitor (1).png
│ │ ├── Monitor (2).png
│ │ ├── Monitor (3).png
│ │ ├── Monitor (4).png
│ │ ├── Monitor (5).png
│ │ ├── Monitor (6).png
│ │ ├── Monitor (7).png
│ │ ├── Monitor.png
│ │ ├── New feature.png
│ │ ├── next-js.svg
│ │ ├── node-js.svg
│ │ ├── openfeature.svg
│ │ ├── posthog.svg
│ │ ├── Pre-Release.png
│ │ ├── react.svg
│ │ ├── Release Goals.png
│ │ ├── Release Stage Beta Targeting Rules v3-min.png
│ │ ├── Release Stage Beta Targeting Rules V3-min.png
│ │ ├── Release Stage Beta Targeting Rules V5-min.png
│ │ ├── Release Stage Beta Targeting Rules-min.png
│ │ ├── remote config - 3.png
│ │ ├── Remote config.png
│ │ ├── Rolling back flags-V2.png
│ │ ├── Rules in other environments.png
│ │ ├── rum-explorer-error-feature-flag-search.7b9f6c046db1de1c71d279c139f1508a.png.avif
│ │ ├── rum-explorer-session-feature-flag-search.435802460fd607608ad5155f029da57b.png.avif
│ │ ├── Satisfaction feedback-min.png
│ │ ├── Satisified-min.png
│ │ ├── Save the segment-min.png
│ │ ├── Saving New Segment-min.png
│ │ ├── Screenshot 2024-08-14 at 19.25.06 (1).png
│ │ ├── Screenshot 2024-08-14 at 19.25.06.png
│ │ ├── Screenshot 2024-08-15 at 13.57.46.png
│ │ ├── Screenshot 2024-10-10 at 14.04.09.png
│ │ ├── Screenshot 2024-10-10 at 14.04.34.png
│ │ ├── Screenshot 2025-07-10 at 14.04.07.png
│ │ ├── Screenshot 2025-07-10 at 14.11.01.png
│ │ ├── Screenshot 2025-07-10 at 14.29.20.png
│ │ ├── Screenshot 2025-07-15 at 21.31.16.png
│ │ ├── Screenshot 2025-07-21 at 20.07.27.png
│ │ ├── Screenshot 2025-09-02 at 17.08.25.png
│ │ ├── Screenshot 2025-09-02 at 17.10.36 (1).png
│ │ ├── Screenshot 2025-09-02 at 17.10.36 (2).png
│ │ ├── Screenshot 2025-09-02 at 17.10.36.png
│ │ ├── Screenshot 2025-09-02 at 17.11.21 (1).png
│ │ ├── Screenshot 2025-09-02 at 17.11.21.png
│ │ ├── Screenshot 2025-09-02 at 17.13.15 (1).png
│ │ ├── Screenshot 2025-09-02 at 17.13.15.png
│ │ ├── Screenshot 2025-09-02 at 17.19.44 (1).png
│ │ ├── Screenshot 2025-09-02 at 17.19.44.png
│ │ ├── Screenshot 2025-09-09 at 09.32.31.png
│ │ ├── Screenshot 2025-09-12 at 11.50.41.png
│ │ ├── Screenshot 2025-09-12 at 12.30.38.png
│ │ ├── Screenshot 2025-09-12 at 13.14.44.png
│ │ ├── Screenshot 2025-09-12 at 13.18.07.png
│ │ ├── Screenshot 2025-09-12 at 13.21.25.png
│ │ ├── Screenshot 2025-09-12 at 13.25.21.png
│ │ ├── Screenshot 2025-09-12 at 14.29.56.png
│ │ ├── Screenshot 2025-09-12 at 14.37.52.png
│ │ ├── Screenshot 2025-09-12 at 14.58.27.png
│ │ ├── Screenshot 2025-09-12 at 15.00.32.png
│ │ ├── Screenshot 2025-09-12 at 15.01.32.png
│ │ ├── Screenshot 2025-09-12 at 15.03.33.png
│ │ ├── Screenshot 2025-09-12 at 15.04.39.png
│ │ ├── Screenshot 2025-09-12 at 15.06.50.png
│ │ ├── Screenshot 2025-09-12 at 15.13.45.png
│ │ ├── Screenshot 2025-09-12 at 15.14.43.png
│ │ ├── Screenshot 2025-09-12 at 15.16.42.png
│ │ ├── Screenshot 2025-09-12 at 15.18.42.png
│ │ ├── Screenshot 2025-09-12 at 15.32.39.png
│ │ ├── Screenshot 2025-09-12 at 15.33.57.png
│ │ ├── Screenshot 2025-09-12 at 15.35.09.png
│ │ ├── Screenshot 2025-09-12 at 15.36.14.png
│ │ ├── segment (1).svg
│ │ ├── segment.svg
│ │ ├── Segments.png
│ │ ├── Set segment conditions-min.png
│ │ ├── Setting multiple targeting rules.png
│ │ ├── Setting Tab-min.png
│ │ ├── Setting targeting rules v3-min.png
│ │ ├── Setting targeting rules-min.png
│ │ ├── Settings-min (1).png
│ │ ├── Settings-min.png
│ │ ├── slack (1).svg
│ │ ├── Slack (with auto-layout)-min.png
│ │ ├── Slack and Environments-min.png
│ │ ├── Slack and Feature views-min.png
│ │ ├── Slack Integration.png
│ │ ├── Slack Settings under Features-min.png
│ │ ├── Slack with User Feedback.png
│ │ ├── slack.svg
│ │ ├── slackConnected (1).png
│ │ ├── slackConnected.png
│ │ ├── slackDisconnected (1).png
│ │ ├── slackDisconnected.png
│ │ ├── STARS Configuration-min.png
│ │ ├── STARS Feature Funnel-min.png
│ │ ├── STARS Feature Report-min.png
│ │ ├── STARS states.png
│ │ ├── surveys-min.png
│ │ ├── Switching Between Environments-min.png
│ │ ├── Targeting rules interface-min.png
│ │ ├── Targeting rules.png
│ │ ├── There are 5 different types of conditions to chose from-min.png
│ │ ├── Track adoption in the UI V2-min.png
│ │ ├── Track adoption in the UI v3-min.png
│ │ ├── Track adoption in the UI-min.png
│ │ ├── Track new feature V2-min.png
│ │ ├── Tracking Tab-min.png
│ │ ├── ts-js.svg
│ │ ├── type-check-failed.png
│ │ ├── type-check-payload-failed.png
│ │ ├── usage attribute example v3.png
│ │ ├── usage attribute example-min.png
│ │ ├── Usage configuration-min.png
│ │ ├── vercel-logo.svg
│ │ ├── vue-logo.svg
│ │ ├── What is the STARS Framework v3-min.png
│ │ └── What is the STARS Framework_-min.png
│ └── includes
│ ├── integrations.md
│ ├── languages.md
│ ├── need-some-help-chat-with-us.md
│ ├── sdks.md
│ └── untitled.md
├── .github
│ └── README.md
├── .vscode
│ └── settings.json
├── api
│ ├── api-access.md
│ ├── cli.md
│ ├── mcp.md
│ ├── public-api
│ │ ├── public-api-reference.md
│ │ └── README.md
│ └── reflag-rest-api
│ ├── README.md
│ └── reflag-api-reference.md
├── guides
│ ├── self-opt-in.md
│ └── use-reflag-in-your-cli.md
├── integrations
│ ├── amplitude.md
│ ├── aws-s3.md
│ ├── cursor.md
│ ├── datadog.md
│ ├── github.md
│ ├── linear.md
│ ├── mixpanel.md
│ ├── overview.md
│ ├── posthog.md
│ ├── segment.md
│ └── slack.md
├── introduction
│ └── concepts
│ ├── app.md
│ ├── company.md
│ ├── environment.md
│ ├── event.md
│ ├── feature-events.md
│ ├── feature-view.md
│ ├── feature.md
│ ├── feedback.md
│ ├── filter.md
│ ├── README.md
│ ├── release-stage.md
│ ├── segment.md
│ ├── targeting-rules.md
│ └── user.md
├── product-handbook
│ ├── anonymous-users.md
│ ├── concepts
│ │ ├── app.md
│ │ ├── company.md
│ │ ├── environment.md
│ │ ├── event.md
│ │ ├── feature-events.md
│ │ ├── feature-view.md
│ │ ├── feature.md
│ │ ├── feedback.md
│ │ ├── filter.md
│ │ ├── README.md
│ │ ├── release-stage.md
│ │ ├── segment.md
│ │ ├── targeting-rules.md
│ │ └── user.md
│ ├── creating-and-managing-apps
│ │ ├── environments.md
│ │ └── README.md
│ ├── creating-and-managing-apps.md
│ ├── creating-segments.md
│ ├── data-export.md
│ ├── data-residency.md
│ ├── feature-clean-up-and-archival-beta
│ │ ├── ai-code-clean-up-beta.md
│ │ └── README.md
│ ├── feature-entitlements
│ │ ├── README.md
│ │ └── simple-role-based-entitlements.md
│ ├── feature-rollouts
│ │ ├── feature-targeting-rules.md
│ │ └── README.md
│ ├── feature-targeting-rules
│ │ ├── creating-segments.md
│ │ └── environments.md
│ ├── feature-views.md
│ ├── launch-monitor
│ │ ├── automated-feedback-surveys.md
│ │ ├── give-feedback-button.md
│ │ └── README.md
│ ├── product-overview.md
│ ├── remote-config.md
│ ├── self-opt-in.md
│ ├── service-resiliency.md
│ ├── team-permissions.md
│ └── type-safety.md
├── README.md
├── sdk
│ ├── _media
│ │ ├── type-check-failed.png
│ │ └── type-check-payload-failed.png
│ ├── @reflag
│ │ ├── browser-sdk
│ │ │ ├── globals.md
│ │ │ └── README.md
│ │ ├── node-sdk
│ │ │ ├── globals.md
│ │ │ └── README.md
│ │ ├── react-sdk
│ │ │ ├── globals.md
│ │ │ └── README.md
│ │ └── vue-sdk
│ │ ├── globals.md
│ │ └── README.md
│ ├── documents
│ │ ├── browser-sdk
│ │ │ └── FEEDBACK.md
│ │ └── cli
│ │ └── README.md
│ └── README.md
├── SUMMARY.md
├── support
│ └── get-support.md
└── supported-languages
├── next.js.md
├── openfeature.md
├── overview.md
└── ruby-rails-stimulus.md
```
# Files
--------------------------------------------------------------------------------
/sdk/@reflag/node-sdk/README.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | layout:
3 | visible: true
4 | title:
5 | visible: true
6 | description:
7 | visible: false
8 | tableOfContents:
9 | visible: true
10 | outline:
11 | visible: true
12 | pagination:
13 | visible: true
14 | ---
15 |
16 | # Reflag Node.js SDK
17 |
18 | Node.js, JavaScript/TypeScript client for [Reflag.com](https://reflag.com).
19 |
20 | Reflag supports flag toggling, tracking flag usage, collecting feedback on features, and [remotely configuring flags](#remote-config).
21 |
22 | ## Installation
23 |
24 | Install using your favorite package manager:
25 |
26 | {% tabs %}
27 | {% tab title="npm" %}
28 |
29 | ```sh
30 | npm i @reflag/node-sdk
31 | ```
32 |
33 | {% endtab %}
34 |
35 | {% tab title="yarn" %}
36 |
37 | ```sh
38 | yarn add @reflag/node-sdk
39 | ```
40 |
41 | {% endtab %}
42 |
43 | {% tab title="bun" %}
44 |
45 | ```sh
46 | bun add @reflag/node-sdk
47 | ```
48 |
49 | {% endtab %}
50 |
51 | {% tab title="pnpm" %}
52 |
53 | ```sh
54 | pnpm add @reflag/node-sdk
55 | ```
56 |
57 | {% endtab %}
58 |
59 | {% tab title="deno" %}
60 |
61 | ```sh
62 | deno add npm:@reflag/node-sdk
63 | ```
64 |
65 | {% endtab %}
66 | {% endtabs %}
67 |
68 | Other supported languages/frameworks are in the [Supported languages](https://docs.reflag.com/quickstart/supported-languages) documentation pages.
69 |
70 | You can also [use the HTTP API directly](https://docs.reflag.com/api/http-api)
71 |
72 | ## Basic usage
73 |
74 | To get started you need to obtain your secret key from the [environment settings](https://app.reflag.com/env-current/settings/app-environments)
75 | in Reflag.
76 |
77 | {% hint style="danger" %}
78 | Secret keys are meant for use in server side SDKs only. Secret keys offer the users the ability to obtain
79 | information that is often sensitive and thus should not be used in client-side applications.
80 | {% endhint %}
81 |
82 | Reflag will load settings through the various environment variables automatically (see [Configuring](#configuring) below).
83 |
84 | 1. Find the Reflag secret key for your development environment under [environment settings](https://app.reflag.com/env-current/settings/app-environments) in Reflag.
85 | 2. Set `REFLAG_SECRET_KEY` in your `.env` file
86 | 3. Create a `reflag.ts` file containing the following:
87 |
88 | ```typescript
89 | import { ReflagClient } from "@reflag/node-sdk";
90 |
91 | // Create a new instance of the client with the secret key. Additional options
92 | // are available, such as supplying a logger and other custom properties.
93 | //
94 | // We recommend that only one global instance of `client` should be created
95 | // to avoid multiple round-trips to our servers.
96 | export const reflagClient = new ReflagClient();
97 |
98 | // Initialize the client and begin fetching flag targeting definitions.
99 | // You must call this method prior to any calls to `getFlags()`,
100 | // otherwise an empty object will be returned.
101 | reflagClient.initialize().then(() => {
102 | console.log("Reflag initialized!");
103 | });
104 | ```
105 |
106 | Once the client is initialized, you can obtain flags along with the `isEnabled`
107 | status to indicate whether the flag is targeted for this user/company:
108 |
109 | {% hint style="warning" %}
110 | If `user.id` or `company.id` is not given, the whole `user` or `company` object is ignored.
111 | {% endhint %}
112 |
113 | ```typescript
114 | // configure the client
115 | const boundClient = reflagClient.bindClient({
116 | user: {
117 | id: "john_doe",
118 | name: "John Doe",
119 | email: "[email protected]",
120 | avatar: "https://example.com/users/jdoe",
121 | },
122 | company: {
123 | id: "acme_inc",
124 | name: "Acme, Inc.",
125 | avatar: "https://example.com/companies/acme",
126 | },
127 | });
128 |
129 | // get the huddle flag using company, user and custom context to
130 | // evaluate the targeting.
131 | const { isEnabled, track, config } = boundClient.getFlag("huddle");
132 |
133 | if (isEnabled) {
134 | // this is your flag gated code ...
135 | // send an event when the flag is used:
136 | track();
137 |
138 | if (config?.key === "zoom") {
139 | // this code will run if a given remote configuration
140 | // is set up.
141 | }
142 |
143 | // CAUTION: if you plan to use the event for automated feedback surveys
144 | // call `flush` immediately after `track`. It can optionally be awaited
145 | // to guarantee the sent happened.
146 | boundClient.flush();
147 | }
148 | ```
149 |
150 | You can also use the `getFlags()` method which returns a map of all flags:
151 |
152 | ```typescript
153 | // get the current flags (uses company, user and custom context to
154 | // evaluate the flags).
155 | const flags = boundClient.getFlags();
156 | const bothEnabled = flags.huddle?.isEnabled && flags.voiceHuddle?.isEnabled;
157 | ```
158 |
159 | ## High performance flag targeting
160 |
161 | The SDK contacts the Reflag servers when you call `initialize()`
162 | and downloads the flags with their targeting rules.
163 | These rules are then matched against the user/company information you provide
164 | to `getFlags()` (or through `bindClient(..).getFlags()`). That means the
165 | `getFlags()` call does not need to contact the Reflag servers once
166 | `initialize()` has completed. `ReflagClient` will continue to periodically
167 | download the targeting rules from the Reflag servers in the background.
168 |
169 | ### Batch Operations
170 |
171 | The SDK automatically batches operations like user/company updates and flag tracking events to minimize API calls.
172 | The batch buffer is configurable through the client options:
173 |
174 | ```typescript
175 | const client = new ReflagClient({
176 | batchOptions: {
177 | maxSize: 100, // Maximum number of events to batch
178 | intervalMs: 1000, // Flush interval in milliseconds
179 | },
180 | });
181 | ```
182 |
183 | You can manually flush the batch buffer at any time:
184 |
185 | ```typescript
186 | await client.flush();
187 | ```
188 |
189 | {% hint style="success" %}
190 | It's recommended to call `flush()` before your application shuts down to ensure all events are sent.
191 | {% endhint %}
192 |
193 | ### Rate Limiting
194 |
195 | The SDK includes automatic rate limiting for flag events to prevent overwhelming the API.
196 | Rate limiting is applied per unique combination of flag key and context. The rate limiter window size is configurable:
197 |
198 | ```typescript
199 | const client = new ReflagClient({
200 | rateLimiterOptions: {
201 | windowSizeMs: 60000, // Rate limiting window size in milliseconds
202 | },
203 | });
204 | ```
205 |
206 | ### Flag definitions
207 |
208 | Flag definitions include the rules needed to determine which flags should be enabled and which config values should be applied to any given user/company.
209 | Flag definitions are automatically fetched when calling `initialize()`.
210 | They are then cached and refreshed in the background.
211 | It's also possible to get the currently in use flag definitions:
212 |
213 | ```typescript
214 | import fs from "fs";
215 |
216 | const client = new ReflagClient();
217 |
218 | const flagDefs = await client.getFlagDefinitions();
219 | // [{
220 | // key: "huddle",
221 | // description: "Live voice conversations with colleagues."
222 | // flag: { ... }
223 | // config: { ... }
224 | // }]
225 | ```
226 |
227 | ## Bootstrapping client-side applications
228 |
229 | The `getFlagsForBootstrap()` method is designed for server-side rendering (SSR) scenarios where you need to pass flag data to client-side applications. This method returns raw flag data without wrapper functions, making it suitable for serialization and client-side hydration.
230 |
231 | ```typescript
232 | const client = new ReflagClient();
233 | await client.initialize();
234 |
235 | // Get flags for bootstrapping with full context
236 | const { context, flags } = client.getFlagsForBootstrap({
237 | user: {
238 | id: "user123",
239 | name: "John Doe",
240 | email: "[email protected]",
241 | },
242 | company: {
243 | id: "company456",
244 | name: "Acme Inc",
245 | plan: "enterprise",
246 | },
247 | other: {
248 | source: "web",
249 | platform: "desktop",
250 | },
251 | });
252 |
253 | // Pass this data to your client-side application
254 | // The flags object contains raw flag data suitable for JSON serialization
255 | console.log(flags);
256 | // {
257 | // "huddle": {
258 | // "key": "huddle",
259 | // "isEnabled": true,
260 | // "config": {
261 | // "key": "enhanced",
262 | // "payload": { "maxParticipants": 50, "videoQuality": "hd" },
263 | // }
264 | // }
265 | // }
266 | ```
267 |
268 | You can also use a bound client for simpler API:
269 |
270 | ```typescript
271 | const boundClient = client.bindClient({
272 | user: { id: "user123", name: "John Doe", email: "[email protected]" },
273 | company: { id: "company456", name: "Acme Inc", plan: "enterprise" },
274 | });
275 |
276 | const { context, flags } = boundClient.getFlagsForBootstrap();
277 | ```
278 |
279 | ### Key differences from `getFlags()`
280 |
281 | - **Raw data**: Returns plain objects without `track()` functions, making them JSON serializable
282 | - **Context included**: Returns both the evaluated flags and the context used for evaluation
283 | - **Bootstrapping focus**: Designed specifically for passing data to client-side applications
284 |
285 | ## Edge-runtimes like Cloudflare Workers
286 |
287 | To use the Reflag NodeSDK with Cloudflare workers, set the `node_compat` flag [in your wrangler file](https://developers.cloudflare.com/workers/runtime-apis/nodejs/#get-started).
288 |
289 | Instead of using `ReflagClient`, use `EdgeClient` and make sure you call `ctx.waitUntil(reflag.flush());` before returning from your worker function.
290 |
291 | ```typescript
292 | import { EdgeClient } from "@reflag/node-sdk";
293 |
294 | // set the REFLAG_SECRET_KEY environment variable or pass the secret key in the constructor
295 | const reflag = new EdgeClient();
296 |
297 | export default {
298 | async fetch(request, _env, ctx): Promise<Response> {
299 | // initialize the client and wait for it to complete
300 | // if the client was initialized on a previous invocation, this is a no-op.
301 | await reflag.initialize();
302 | const flags = reflag.getFlags({
303 | user: { id: "userId" },
304 | company: { id: "companyId" },
305 | });
306 |
307 | // ensure all events are flushed and any requests to refresh the flag cache
308 | // have completed after the response is sent
309 | ctx.waitUntil(reflag.flush());
310 |
311 | return new Response(
312 | `Flags for user ${userId} and company ${companyId}: ${JSON.stringify(flags, null, 2)}`,
313 | );
314 | },
315 | };
316 | ```
317 |
318 | See [examples/cloudflare-worker](https://github.com/reflagcom/javascript/tree/main/packages/node-sdk/examples/cloudflare-worker/src/index.ts) for a deployable example.
319 |
320 | Reflag maintains a cached set of flag definitions in the memory of your worker which it uses to decide which flags to turn on for which users/companies.
321 |
322 | The SDK caches flag definitions in memory for fast performance. The first request to a new worker instance fetches definitions from Reflag's servers, while subsequent requests use the cache. When the cache expires, it's updated in the background. `ctx.waitUntil(reflag.flush())` ensures completion of the background work, so response times are not affected. This background work may increase wall-clock time for your worker, but it will not measurably increase billable CPU time on platforms like Cloudflare.
323 |
324 | ## Error Handling
325 |
326 | The SDK is designed to fail gracefully and never throw exceptions to the caller. Instead, it logs errors and provides
327 | fallback behavior:
328 |
329 | 1. **Flag Evaluation Failures**:
330 |
331 | ```typescript
332 | const { isEnabled } = client.getFlag("my-flag");
333 | // If flag evaluation fails, isEnabled will be false
334 | ```
335 |
336 | 2. **Network Errors**:
337 |
338 | ```typescript
339 | // Network errors during tracking are logged but don't affect your application
340 | const { isEnabled, track } = client.getFlag("my-flag");
341 | if (isEnabled) {
342 | // network errors are caught internally and logged and never bubbled up to your application
343 | // no need to try/catch around "track" or "getFlag"
344 | await track();
345 | }
346 | ```
347 |
348 | 3. **Missing Context**:
349 |
350 | ```typescript
351 | // The SDK tracks missing context fields but continues operation
352 | const flags = client.getFlags({
353 | user: { id: "user123" },
354 | // Missing company context will be logged but won't cause errors
355 | });
356 | ```
357 |
358 | 4. **Offline Mode**:
359 |
360 | ```typescript
361 | // In offline mode, the SDK uses flag overrides
362 | const client = new ReflagClient({
363 | offline: true,
364 | flagOverrides: () => ({
365 | "my-flag": true,
366 | }),
367 | });
368 | ```
369 |
370 | The SDK logs all errors with appropriate severity levels. You can customize logging by providing your own logger:
371 |
372 | ```typescript
373 | const client = new ReflagClient({
374 | logger: {
375 | debug: (msg) => console.debug(msg),
376 | info: (msg) => console.info(msg),
377 | warn: (msg) => console.warn(msg),
378 | error: (msg, error) => {
379 | console.error(msg, error);
380 | // Send to your error tracking service
381 | errorTracker.capture(error);
382 | },
383 | },
384 | });
385 | ```
386 |
387 | ## Remote config
388 |
389 | Remote config is a dynamic and flexible approach to configuring flag behavior outside of your app – without needing to re-deploy it.
390 |
391 | Similar to `isEnabled`, each flag has a `config` property. This configuration is managed from within Reflag.
392 | It is managed similar to the way access to flags is managed, but instead of the binary `isEnabled` you can have
393 | multiple configuration values which are given to different user/companies.
394 |
395 | ```ts
396 | const flags = reflagClient.getFlags();
397 | // {
398 | // huddle: {
399 | // isEnabled: true,
400 | // targetingVersion: 42,
401 | // config: {
402 | // key: "gpt-3.5",
403 | // payload: { maxTokens: 10000, model: "gpt-3.5-beta1" }
404 | // }
405 | // }
406 | // }
407 | ```
408 |
409 | `key` is mandatory for a config, but if a flag has no config or no config value was matched against the context, the `key` will be `undefined`. Make sure to check against this case when trying to use the configuration in your application. `payload` is an optional JSON value for arbitrary configuration needs.
410 |
411 | Just as `isEnabled`, accessing `config` on the object returned by `getFlags` does not automatically
412 | generate a `check` event, contrary to the `config` property on the object returned by `getFlag`.
413 |
414 | ## Configuring
415 |
416 | The Reflag `Node.js` SDK can be configured through environment variables,
417 | a configuration file on disk or by passing options to the `ReflagClient`
418 | constructor. By default, the SDK searches for `reflag.config.json` in the
419 | current working directory.
420 |
421 | | Option | Type | Description | Env Var |
422 | | --------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
423 | | `secretKey` | string | The secret key used for authentication with Reflag's servers. | REFLAG_SECRET_KEY |
424 | | `logLevel` | string | The log level for the SDK (e.g., `"DEBUG"`, `"INFO"`, `"WARN"`, `"ERROR"`). Default: `INFO` | REFLAG_LOG_LEVEL |
425 | | `offline` | boolean | Operate in offline mode. Default: `false`, except in tests it will default to `true` based off of the `TEST` env. var. | REFLAG_OFFLINE |
426 | | `apiBaseUrl` | string | The base API URL for the Reflag servers. | REFLAG_API_BASE_URL |
427 | | `flagOverrides` | Record<string, boolean> | An object specifying flag overrides for testing or local development. See [examples/express/app.test.ts](https://github.com/reflagcom/javascript/tree/main/packages/node-sdk/examples/express/app.test.ts) for how to use `flagOverrides` in tests. | REFLAG_FLAGS_ENABLED, REFLAG_FLAGS_DISABLED |
428 | | `configFile` | string | Load this config file from disk. Default: `reflag.config.json` | REFLAG_CONFIG_FILE |
429 |
430 | {% hint style="info" %}
431 | {% endhint %}
432 |
433 | `reflag.config.json` example:
434 |
435 | ```json
436 | {
437 | "secretKey": "...",
438 | "logLevel": "warn",
439 | "offline": true,
440 | "apiBaseUrl": "https://proxy.slick-demo.com",
441 | "flagOverrides": {
442 | "huddles": true,
443 | "voiceChat": { "isEnabled": false },
444 | "aiAssist": {
445 | "isEnabled": true,
446 | "config": {
447 | "key": "gpt-4.0",
448 | "payload": {
449 | "maxTokens": 50000
450 | }
451 | }
452 | }
453 | }
454 | }
455 | ```
456 |
457 | When using a `reflag.config.json` for local development, make sure you add it to your
458 | `.gitignore` file. You can also set these options directly in the `ReflagClient`
459 | constructor. The precedence for configuration options is as follows, listed in the
460 | order of importance:
461 |
462 | 1. Options passed along to the constructor directly,
463 | 2. Environment variable,
464 | 3. The config file.
465 |
466 | ## Type safe flags
467 |
468 | To get type checked flags, install the Reflag CLI:
469 |
470 | ```sh
471 | npm i --save-dev @reflag/cli
472 | ```
473 |
474 | then generate the types:
475 |
476 | ```sh
477 | npx reflag flags types
478 | ```
479 |
480 | This will generate a `reflag.d.ts` containing all your flags.
481 | Any flag look ups will now be checked against the flags that exist in Reflag.
482 |
483 | Here's an example of a failed type check:
484 |
485 | ```typescript
486 | import { ReflagClient } from "@reflag/node-sdk";
487 |
488 | export const reflagClient = new ReflagClient();
489 |
490 | reflagClient.initialize().then(() => {
491 | console.log("Reflag initialized!");
492 |
493 | // TypeScript will catch this error: "invalid-flag" doesn't exist
494 | reflagClient.getFlag("invalid-flag");
495 |
496 | const {
497 | isEnabled,
498 | config: { payload },
499 | } = reflagClient.getFlag("create-todos");
500 | });
501 | ```
502 |
503 | 
504 |
505 | This is an example of a failed config payload check:
506 |
507 | ```typescript
508 | reflagClient.initialize().then(() => {
509 | // TypeScript will catch this error as well: "minLength" is not part of the payload.
510 | if (isEnabled && todo.length > config.payload.minLength) {
511 | // ...
512 | }
513 | });
514 | ```
515 |
516 | 
517 |
518 | ## Testing
519 |
520 | When writing tests that cover code with flags, you can toggle flags on/off programmatically to test the different behavior.
521 |
522 | `reflag.ts`:
523 |
524 | ```typescript
525 | import { ReflagClient } from "@reflag/node-sdk";
526 |
527 | export const reflag = new ReflagClient();
528 | ```
529 |
530 | `app.test.ts`:
531 |
532 | ```typescript
533 | import { reflag } from "./reflag.ts";
534 |
535 | beforeAll(async () => await reflag.initialize());
536 | afterEach(() => {
537 | reflag.clearFlagOverrides();
538 | });
539 |
540 | describe("API Tests", () => {
541 | it("should return 200 for the root endpoint", async () => {
542 | reflag.flagOverrides = {
543 | "show-todo": true,
544 | };
545 |
546 | const response = await request(app).get("/");
547 | expect(response.status).toBe(200);
548 | expect(response.body).toEqual({ message: "Ready to manage some TODOs!" });
549 | });
550 | });
551 | ```
552 |
553 | See more on flag overrides in the section below.
554 |
555 | ## Flag Overrides
556 |
557 | Flag overrides allow you to override flags and their configurations locally. This is particularly useful for development and testing. You can specify overrides in three ways:
558 |
559 | 1. Through environment variables:
560 |
561 | ```bash
562 | REFLAG_FLAGS_ENABLED=flag1,flag2
563 | REFLAG_FLAGS_DISABLED=flag3,flag4
564 | ```
565 |
566 | 1. Through `reflag.config.json`:
567 |
568 | ```json
569 | {
570 | "flagOverrides": {
571 | "delete-todos": {
572 | "isEnabled": true,
573 | "config": {
574 | "key": "dev-config",
575 | "payload": {
576 | "requireConfirmation": true,
577 | "maxDeletionsPerDay": 5
578 | }
579 | }
580 | }
581 | }
582 | }
583 | ```
584 |
585 | 1. Programmatically through the client options:
586 |
587 | You can use a simple `Record<string, boolean>` and pass it either in the constructor or by setting `client.flagOverrides`:
588 |
589 | ```typescript
590 | // pass directly in the constructor
591 | const client = new ReflagClient({ flagOverrides: { myFlag: true } });
592 | // or set on the client at a later time
593 | client.flagOverrides = { myFlag: false };
594 |
595 | // clear flag overrides. Same as setting to {}.
596 | client.clearFlagOverrides();
597 | ```
598 |
599 | To get dynamic overrides, use a function which takes a context and returns a boolean or an object with the shape of `{isEnabled, config}`:
600 |
601 | ```typescript
602 | import { ReflagClient, Context } from "@reflag/node-sdk";
603 |
604 | const flagOverrides = (context: Context) => ({
605 | "delete-todos": {
606 | isEnabled: true,
607 | config: {
608 | key: "dev-config",
609 | payload: {
610 | requireConfirmation: true,
611 | maxDeletionsPerDay: 5,
612 | },
613 | },
614 | },
615 | });
616 |
617 | const client = new ReflagClient({
618 | flagOverrides,
619 | });
620 | ```
621 |
622 | ## Remote Flag Evaluation
623 |
624 | In addition to local flag evaluation, Reflag supports remote evaluation using stored context. This is useful when you want to evaluate flags using user/company attributes that were previously sent to Reflag:
625 |
626 | ```typescript
627 | // First, update user and company attributes
628 | await client.updateUser("user123", {
629 | attributes: {
630 | role: "admin",
631 | subscription: "premium",
632 | },
633 | });
634 |
635 | await client.updateCompany("company456", {
636 | attributes: {
637 | tier: "enterprise",
638 | employees: 1000,
639 | },
640 | });
641 |
642 | // Later, evaluate flags remotely using stored context
643 | const flags = await client.getFlagsRemote("company456", "user123");
644 | // Or evaluate a single flag
645 | const flag = await client.getFlagRemote(
646 | "create-todos",
647 | "company456",
648 | "user123",
649 | );
650 |
651 | // You can also provide additional context
652 | const flagsWithContext = await client.getFlagsRemote("company456", "user123", {
653 | other: {
654 | location: "US",
655 | platform: "mobile",
656 | },
657 | });
658 | ```
659 |
660 | Remote evaluation is particularly useful when:
661 |
662 | - You want to use the most up-to-date user/company attributes stored in Reflag
663 | - You don't want to pass all context attributes with every evaluation
664 | - You need to ensure consistent flag evaluation across different services
665 |
666 | ## Using with Express
667 |
668 | A popular way to integrate the Reflag Node.js SDK is through an express middleware.
669 |
670 | ```typescript
671 | import reflag from "./reflag";
672 | import express from "express";
673 | import { BoundReflagClient } from "@reflag/node-sdk";
674 |
675 | // Augment the Express types to include a `boundReflagClient` property on the
676 | // `res.locals` object.
677 | // This will allow us to access the ReflagClient instance in our route handlers
678 | // without having to pass it around manually
679 | declare global {
680 | namespace Express {
681 | interface Locals {
682 | boundReflagClient: BoundReflagClient;
683 | }
684 | }
685 | }
686 |
687 | // Add express middleware
688 | app.use((req, res, next) => {
689 | // Extract the user and company IDs from the request
690 | // You'll want to use a proper authentication and identification
691 | // mechanism in a real-world application
692 | const user = {
693 | id: req.user?.id,
694 | name: req.user?.name,
695 | email: req.user?.email
696 | }
697 |
698 | const company = {
699 | id: req.user?.companyId,
700 | name: req.user?.companyName
701 | }
702 |
703 | // Create a new BoundReflagClient instance by calling the `bindClient`
704 | // method on a `ReflagClient` instance
705 | // This will create a new instance that is bound to the user/company given.
706 | const boundReflagClient = reflag.bindClient({ user, company });
707 |
708 | // Store the BoundReflagClient instance in the `res.locals` object so we
709 | // can access it in our route handlers
710 | res.locals.boundReflagClient = boundReflagClient;
711 | next();
712 | });
713 |
714 | // Now use res.locals.boundReflagClient in your handlers
715 | app.get("/todos", async (_req, res) => {
716 | const { track, isEnabled } = res.locals.boundReflagClient.getFlag("show-todos");
717 |
718 | if (!isEnabled) {
719 | res.status(403).send({"error": "flag inaccessible"})
720 | return
721 | }
722 |
723 | ...
724 | }
725 | ```
726 |
727 | See [examples/express/app.ts](https://github.com/reflagcom/javascript/tree/main/packages/node-sdk/example/express/app.ts) for a full example.
728 |
729 | ## Remote flag evaluation with stored context
730 |
731 | If you don't want to provide context each time when evaluating flags but
732 | rather you would like to utilize the attributes you sent to Reflag previously
733 | (by calling `updateCompany` and `updateUser`) you can do so by calling `getFlagsRemote`
734 | (or `getFlagRemote` for a specific flag) with providing just `userId` and `companyId`.
735 | These methods will call Reflag's servers and flags will be evaluated remotely
736 | using the stored attributes.
737 |
738 | ```typescript
739 | // Update user and company attributes
740 | client.updateUser("john_doe", {
741 | attributes: {
742 | name: "John O.",
743 | role: "admin",
744 | },
745 | });
746 |
747 | client.updateCompany("acme_inc", {
748 | attributes: {
749 | name: "Acme, Inc",
750 | tier: "premium"
751 | },
752 | });
753 | ...
754 |
755 | // This will evaluate flags with respecting the attributes sent previously
756 | const flags = await client.getFlagsRemote("acme_inc", "john_doe");
757 | ```
758 |
759 | {% hint style="warning" %}
760 | User and company attribute updates are processed asynchronously, so there might
761 | be a small delay between when attributes are updated and when they are available
762 | for evaluation.
763 | {% endhint %}
764 |
765 | ## Opting out of tracking
766 |
767 | There are use cases in which you not want to be sending `user`, `company` and
768 | `track` events to [Reflag.com](https://reflag.com). These are usually cases where you could be impersonating
769 | another user in the system and do not want to interfere with the data being
770 | collected by Reflag.
771 |
772 | To disable tracking, bind the client using `bindClient()` as follows:
773 |
774 | ```typescript
775 | // binds the client to a given user and company and set `enableTracking` to `false`.
776 | const boundClient = client.bindClient({ user, company, enableTracking: false });
777 |
778 | boundClient.track("some event"); // this will not actually send the event to Reflag.
779 |
780 | // the following code will not update the `user` nor `company` in Reflag and will
781 | // not send `track` events either.
782 | const { isEnabled, track } = boundClient.getFlag("user-menu");
783 | if (isEnabled) {
784 | track();
785 | }
786 | ```
787 |
788 | Another way way to disable tracking without employing a bound client is to call `getFlag()`
789 | or `getFlags()` by supplying `enableTracking: false` in the arguments passed to
790 | these functions.
791 |
792 | {% hint style="warning" %}
793 | Note, however, that calling `track()`, `updateCompany()` or `updateUser()` in the `ReflagClient`
794 | will still send tracking data. As such, it is always recommended to use `bindClient()`
795 | when using this SDK.
796 | {% endhint %}
797 |
798 | ## Flushing
799 |
800 | ReflagClient employs a batching technique to minimize the number of calls that are sent to
801 | Reflag's servers.
802 |
803 | By default, the SDK automatically subscribes to process exit signals and attempts to flush
804 | any pending events. This behavior is controlled by the `flushOnExit` option in the client configuration:
805 |
806 | ```typescript
807 | const client = new ReflagClient({
808 | batchOptions: {
809 | flushOnExit: false, // disable automatic flushing on exit
810 | },
811 | });
812 | ```
813 |
814 | ## Tracking custom events and setting custom attributes
815 |
816 | Tracking allows events and updating user/company attributes in Reflag.
817 | For example, if a customer changes their plan, you'll want Reflag to know about it,
818 | in order to continue to provide up-do-date targeting information in the Reflag interface.
819 |
820 | The following example shows how to register a new user, associate it with a company
821 | and finally update the plan they are on.
822 |
823 | ```typescript
824 | // registers the user with Reflag using the provided unique ID, and
825 | // providing a set of custom attributes (can be anything)
826 | client.updateUser("user_id", {
827 | attributes: { longTimeUser: true, payingCustomer: false },
828 | });
829 | client.updateCompany("company_id", { userId: "user_id" });
830 |
831 | // the user started a voice huddle
832 | client.track("user_id", "huddle", { attributes: { voice: true } });
833 | ```
834 |
835 | It's also possible to achieve the same through a bound client in the following manner:
836 |
837 | ```typescript
838 | const boundClient = client.bindClient({
839 | user: { id: "user_id", longTimeUser: true, payingCustomer: false },
840 | company: { id: "company_id" },
841 | });
842 |
843 | boundClient.track("huddle", { attributes: { voice: true } });
844 | ```
845 |
846 | Some attributes are used by Reflag to improve the UI, and are recommended
847 | to provide for easier navigation:
848 |
849 | - `name` -- display name for `user`/`company`,
850 | - `email` -- the email of the user,
851 | - `avatar` -- the URL for `user`/`company` avatar image.
852 |
853 | Attributes cannot be nested (multiple levels) and must be either strings,
854 | integers or booleans.
855 |
856 | ## Managing `Last seen`
857 |
858 | By default `updateUser`/`updateCompany` calls automatically update the given
859 | user/company `Last seen` property on Reflag servers.
860 |
861 | You can control if `Last seen` should be updated when the events are sent by setting
862 | `meta.active = false`. This is often useful if you
863 | have a background job that goes through a set of companies just to update their
864 | attributes but not their activity.
865 |
866 | Example:
867 |
868 | ```typescript
869 | client.updateUser("john_doe", {
870 | attributes: { name: "John O." },
871 | meta: { active: true },
872 | });
873 |
874 | client.updateCompany("acme_inc", {
875 | attributes: { name: "Acme, Inc" },
876 | meta: { active: false },
877 | });
878 | ```
879 |
880 | `bindClient()` updates attributes on the Reflag servers but does not automatically
881 | update `Last seen`.
882 |
883 | ## Zero PII
884 |
885 | The Reflag SDK doesn't collect any metadata and HTTP IP addresses are _not_ being
886 | stored. For tracking individual users, we recommend using something like database
887 | ID as userId, as it's unique and doesn't include any PII (personal identifiable
888 | information). If, however, you're using e.g. email address as userId, but prefer
889 | not to send any PII to Reflag, you can hash the sensitive data before sending
890 | it to Reflag:
891 |
892 | ```typescript
893 | import { sha256 } from 'crypto-hash';
894 |
895 | client.updateUser({ userId: await sha256("john_doe"), ... });
896 | ```
897 |
898 | ## Migrating from Bucket SDK
899 |
900 | If you have been using the Bucket SDKs previously, the following list will help you migrate to Reflag SDK:
901 |
902 | - `Bucket*` classes, and types have been renamed to `Reflag*` (e.g. `BucketClient` is now `ReflagClient`)
903 | - `Feature*` classes, and types have been renamed to `Flag*` (e.g. `Feature` is now `Flag`, `RawFeatures` is now `RawFlags`)
904 | - When using strongly-typed flags, the new `Flags` interface replaced `Features` interface
905 | - All methods that contained `feature` in the name have been renamed to use the `flag` terminology (e.g. `getFeature` is `getFlag`)
906 | - All environment variables that were prefixed with `BUCKET_` are now prefixed with `REFLAG_`
907 | - The `BUCKET_HOST` environment variable and `host` option have been removed from `ReflagClient` constructor, use `REFLAG_API_BASE_URL` instead
908 | - The `BUCKET_FEATURES_ENABLED` and `BUCKET_FEATURES_DISABLED` have been renamed to `REFLAG_FLAGS_ENABLED` and `REFLAG_FLAGS_DISABLED`
909 | - The default configuration file has been renamed from `bucketConfig.json` to `reflag.config.json`
910 | - The `fallbackFeatures` property in client constructor and configuration files has been renamed to `fallbackFlags`
911 | - `featureKey` has been renamed to `flagKey` in all methods that accepts that argument
912 | - The SDKs will not emit `evaluate` and `evaluate-config` events anymore
913 |
914 | ## Typescript
915 |
916 | Types are bundled together with the library and exposed automatically when importing
917 | through a package manager.
918 |
919 | ## License
920 |
921 | > MIT License
922 | > Copyright (c) 2025 Bucket ApS
923 |
```
--------------------------------------------------------------------------------
/.vscode/settings.json:
--------------------------------------------------------------------------------
```json
1 | {
2 | "cSpell.words": [
3 | "gitbook",
4 | "Reflag"
5 | ]
6 | }
7 |
```
--------------------------------------------------------------------------------
/.gitbook/includes/need-some-help-chat-with-us.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | title: Need some help? Chat with us
3 | ---
4 |
5 | * Need some help? [Chat with us](mailto:[email protected])
6 |
```
--------------------------------------------------------------------------------
/support/get-support.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Need support? We're here to help
3 | ---
4 |
5 | # Get support
6 |
7 | * Need some help? [Chat with us](mailto:[email protected])
8 | * Do you prefer a video call? [Talk to a founder](https://reflag.com/contact)
9 |
10 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/feature-view.md:
--------------------------------------------------------------------------------
```markdown
1 | # Flag view
2 |
3 | ### Definition
4 |
5 | A view is a simple grouping of multiple [flags](feature.md). It offers the ability to set up notifications and generally see the details of the associated flags in one glance.
6 |
7 | ### Next steps
8 |
9 | * Learn how to [manage views](../feature-views.md) within Reflag UI.
10 |
```
--------------------------------------------------------------------------------
/introduction/concepts/feature-view.md:
--------------------------------------------------------------------------------
```markdown
1 | # Feature view
2 |
3 | ### Definition
4 |
5 | A feature view is a simple grouping of multiple [features](feature.md). It offers the ability to set up notifications and generally see the details of the associated features in one glance.
6 |
7 | ### Next steps
8 |
9 | * Learn how to [manage feature views](../../product-handbook/feature-views.md) within Reflag UI.
10 |
```
--------------------------------------------------------------------------------
/integrations/overview.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Integrate Reflag with your stack.
3 | ---
4 |
5 | # Overview
6 |
7 | ## All integrations
8 |
9 | These integrations are crafted and maintained by the Reflag team.
10 |
11 | {% include "../.gitbook/includes/integrations.md" %}
12 |
13 | ## **Build your own**
14 |
15 | To build your own integrations with Reflag, you can use:
16 |
17 | * [Event listeners](../sdk/@reflag/browser-sdk/#event-listeners)
18 | * [HTTP API](../api/public-api/)
19 |
20 | **To request support for more integrations,** [**please fill out this form**](https://share-eu1.hsforms.com/14DktM5t6T229b5Bg8KPDBg2b6w1x) **— Thanks!**
21 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/release-stage.md:
--------------------------------------------------------------------------------
```markdown
1 | # Release stage
2 |
3 | ### Definition
4 |
5 | Release stages in Reflag are entities that allow setting up [app](app.md)-wide [feature access](feature.md#access) targeting rules. Each release stage defines [targeting rules](targeting-rules.md) for each available [environment](environment.md). Later, during the development of new features, you can apply all those rule automatically by selecting an available release stage.
6 |
7 | Release stages are useful tools when a standard release workflow is used in your organization.
8 |
9 | ### Next steps
10 |
11 | * Learn about [filters](filter.md) and [targeting rules](targeting-rules.md)
12 |
13 |
```
--------------------------------------------------------------------------------
/supported-languages/overview.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | Reflag SDKs for React, Vue.js, Node.js, Next.js, and more. Supports
4 | OpenFeature.
5 | ---
6 |
7 | # Overview
8 |
9 | ## Official SDKs
10 |
11 | These SDKs are crafted and maintained by the Reflag team.
12 |
13 | {% include "../.gitbook/includes/sdks.md" %}
14 |
15 | ## Unofficial SDKs
16 |
17 | The following SDKs are community-led.
18 |
19 | * [Ruby on Rails](ruby-rails-stimulus.md) by [mikker](https://gist.github.com/mikker)
20 |
21 | For non-supported languages, you can use the [HTTP API](../api/public-api/).
22 |
23 | To request support for more languages, [please fill out this form](https://share-eu1.hsforms.com/14DktM5t6T229b5Bg8KPDBg2b6w1x). 
24 |
```
--------------------------------------------------------------------------------
/introduction/concepts/release-stage.md:
--------------------------------------------------------------------------------
```markdown
1 | # Release stage
2 |
3 | ### Definition
4 |
5 | Release stages in Reflag are entities that allow setting up [app](app.md)-wide [feature access](feature.md#access) targeting rules. Each release stage defines [targeting rules](targeting-rules.md) for each available [environment](environment.md). Later, during the development of new features, you can apply all those rule automatically by selecting an available release stage.
6 |
7 | Release stages are useful tools when a standard release workflow is used in your organization.
8 |
9 | ### Next steps
10 |
11 | * Learn about [filters](filter.md) and [targeting rules](targeting-rules.md),
12 | * Learn how to [manage release stages](broken-reference) within Reflag UI.
13 |
14 |
```
--------------------------------------------------------------------------------
/supported-languages/ruby-rails-stimulus.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How to use Reflag with Rails and Stimulus
3 | hidden: true
4 | ---
5 |
6 | # Ruby SDK
7 |
8 | How to use Reflag with Rails (+ Stimulus). Created by [mikker](https://gist.github.com/mikker) on [GitHub](https://gist.github.com/mikker/c435fc6bfcbdf67b60cd12ff96a45ee5).
9 |
10 | {% embed url="https://gist.github.com/mikker/c435fc6bfcbdf67b60cd12ff96a45ee5#file-application-html-erb" %}
11 |
12 | {% embed url="https://gist.github.com/mikker/c435fc6bfcbdf67b60cd12ff96a45ee5#file-application_controller-rb" %}
13 |
14 | {% embed url="https://gist.github.com/mikker/c435fc6bfcbdf67b60cd12ff96a45ee5#file-bucket_controller-js" %}
15 |
16 | {% embed url="https://gist.github.com/mikker/c435fc6bfcbdf67b60cd12ff96a45ee5#file-index-html-erb" %}
17 |
```
--------------------------------------------------------------------------------
/product-handbook/creating-and-managing-apps.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Learn more about apps in Reflag
3 | ---
4 |
5 | # Managing apps
6 |
7 | Learn about [apps](../introduction/concepts/app.md) here.
8 |
9 | ### Modifying or deleting an app
10 |
11 | * On the sidebar, click `Settings`
12 | * Under the `App:[App Name]` heading, click `General`
13 | * You can modify the `App name`
14 | * You can delete the app by clicking the `Delete app` button
15 |
16 | <figure><img src="../.gitbook/assets/Modifying or deleting an app-min.png" alt="Reflag Global Settings page"><figcaption></figcaption></figure>
17 |
18 | ### Creating a new app
19 |
20 | If you have multiple products or applications, you can create additional apps.
21 |
22 | * Click on `[Current app name]`, found in the top-left corner
23 | * In the tab that appears, click `New app`
24 | * Name the app and click `Create`
25 |
```
--------------------------------------------------------------------------------
/product-handbook/launch-monitor/give-feedback-button.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Adding a feedback button using Reflag SDKs in a few lines of code.
3 | ---
4 |
5 | # Give feedback button
6 |
7 | Collecting feedback through a "Give feedback" button is a great way to collect feedback from users.
8 |
9 | Here's a brief example using the [Reflag React SDK](../../sdk/@reflag/browser-sdk/):
10 |
11 | ```tsx
12 | import { useFlag } from "@reflag/react-sdk";
13 |
14 | function StartHuddleButton() {
15 | const { isLoading, isEnabled, track, requestFeedback } = useFlag("huddle");
16 |
17 | if (isLoading) {
18 | return <Loading />;
19 | }
20 |
21 | if (!isEnabled) {
22 | return null;
23 | }
24 |
25 | return (
26 | <>
27 | <button onClick={track}>Start huddle!</button>
28 | <button
29 | onClick={() => requestFeedback({ title: "How do you like Huddles?" })}
30 | >
31 | Give feedback!
32 | </button>
33 | </>
34 | );
35 | }
36 | ```
37 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/app.md:
--------------------------------------------------------------------------------
```markdown
1 | # App
2 |
3 | An **app** maps to a product or application that you track within Reflag. You can have multiple apps setup within Reflag.
4 |
5 | An app can have multiple [environments](environment.md) with features within it.
6 |
7 | ### Definition
8 |
9 | An **app** maps to a product or application that you track within Reflag. You can have multiple apps setup within Reflag.
10 |
11 | The following entities are managed at the app level: 
12 |
13 | * [Features](feature.md)
14 | * [Feature views](feature-view.md)
15 | * [Company segments](segment.md)
16 | * [Release stages](release-stage.md)
17 |
18 | While the definitions of features and company segments are app-wide, the data they aggregate is [environment](environment.md) specific.
19 |
20 | ### Next steps
21 |
22 | * Learn about [features](feature.md) or [company segments](segment.md),
23 | * Learn how to [manage your apps](../creating-and-managing-apps/) within Reflag UI.
24 |
25 | \
26 | \
27 |
```
--------------------------------------------------------------------------------
/introduction/concepts/app.md:
--------------------------------------------------------------------------------
```markdown
1 | # App
2 |
3 | An **app** maps to a product or application that you track within Reflag. You can have multiple apps setup within Reflag.
4 |
5 | An app can have multiple [environments](environment.md) with features within it.
6 |
7 | ### Definition
8 |
9 | An **app** maps to a product or application that you track within Reflag. You can have multiple apps setup within Reflag.
10 |
11 | The following entities are managed at the app level: 
12 |
13 | * [Features](feature.md)
14 | * [Feature views](feature-view.md)
15 | * [Company segments](segment.md)
16 | * [Release stages](release-stage.md)
17 |
18 | While the definitions of features and company segments are app-wide, the data they aggregate is [environment](environment.md) specific.
19 |
20 | ### Next steps
21 |
22 | * Learn about [features](feature.md) or [company segments](segment.md),
23 | * Learn how to [manage your apps](../../product-handbook/creating-and-managing-apps.md) within Reflag UI.
24 |
25 | \
26 | \
27 |
```
--------------------------------------------------------------------------------
/integrations/segment.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Use Segment events for tracking feature adoption metrics on Reflag
3 | ---
4 |
5 | # Segment
6 |
7 | Reflag's segment integration is for customers who already use Segment for event tracking and want to use those events for tracking feature adoption metrics on Reflag.
8 |
9 | ## Getting started
10 |
11 | 1. Set up [Reflag Cloud destination](https://app.segment.com/goto-my-workspace/destinations/catalog/bucket) to receive data from a Segment source.
12 |
13 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-09 at 09.32.31.png" alt=""><figcaption></figcaption></figure>
14 | 2. Copy your **Reflag Publishable key** from the Environments page in Settings and add it to the `API Key` settings field in the destination.
15 | 3. Enable the destination.
16 | 4. Check the Tracking page in Reflag to ensure the data arrives. Data should start flowing immediately.
17 |
18 | ## Supported types
19 |
20 | Reflag supports `analytics.track(),` `analytics.identify()` and `analytics.group()` , but doesn't support the Segment `analytics.page()` , which are ignored.
21 |
22 |
```
--------------------------------------------------------------------------------
/api/reflag-rest-api/reflag-api-reference.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | Describes the REST API that allows clients to manage and update apps, flags
4 | and related entities.
5 | ---
6 |
7 | # API Reference
8 |
9 | {% openapi-operation spec="reflag-api" path="/apps" method="get" %}
10 | [OpenAPI reflag-api](https://app.reflag.com/openapi.json)
11 | {% endopenapi-operation %}
12 |
13 | {% openapi-operation spec="reflag-api" path="/apps/{appId}" method="get" %}
14 | [OpenAPI reflag-api](https://app.reflag.com/openapi.json)
15 | {% endopenapi-operation %}
16 |
17 | {% openapi-operation spec="reflag-api" path="/apps/{appId}/flags" method="get" %}
18 | [OpenAPI reflag-api](https://app.reflag.com/openapi.json)
19 | {% endopenapi-operation %}
20 |
21 | {% openapi-operation spec="reflag-api" path="/apps/{appId}/flags/{flagKey}/targeting/{envId}" method="get" %}
22 | [OpenAPI reflag-api](https://app.reflag.com/openapi.json)
23 | {% endopenapi-operation %}
24 |
25 | {% openapi-operation spec="reflag-api" path="/apps/{appId}/flags/specific-targets/{envId}" method="patch" %}
26 | [OpenAPI reflag-api](https://app.reflag.com/openapi.json)
27 | {% endopenapi-operation %}
28 |
```
--------------------------------------------------------------------------------
/integrations/cursor.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How to create feature flags in Cursor
3 | ---
4 |
5 | # Cursor
6 |
7 | ### Rule
8 |
9 | Create a Project Rule called `.cursor/rules/featureflags.md`. Here's a template you can use:
10 |
11 | ```markdown
12 | We use Reflag (https://reflag.com) for feature flagging and feature management.
13 |
14 | Reflag's documentation is located at https://docs.reflag.com
15 | You can create feature flags using the CLI (@reflag/cli).
16 |
17 | If installed, you can use the the Reflag MCP to create flags.
18 | Alternatively, try this command to use the Reflag CLI: npx reflag new
19 | ```
20 |
21 | ### Slash Command
22 |
23 | Create a slash command called `.cursor/commands/flag.md` Here's a template you can use:
24 |
25 | ```
26 | Feature flag the changes
27 |
28 | 1. Create a feature flag with Reflag with an appropriate name
29 | 2. Update the code to ensure changes are flagged
30 |
31 | The Reflag documentation is located at https://docs.reflag.com
32 | If installed, use the CLI to create a feature flag using the command: npx reflag new
33 | If the Reflag MCP is installed, you can create a flag through the Reflag MCP
34 | ```
35 |
36 | ### MCP
37 |
38 | See [mcp.md](../api/mcp.md "mention") page for Cursor instructions
39 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/feedback.md:
--------------------------------------------------------------------------------
```markdown
1 | # Feedback
2 |
3 | ### Definition
4 |
5 | A feedback entity in Reflag is sent by the client when an user provides feedback within your application. You must be using Reflag SDKs to gain access to feedback collection functionality. Feedback can be submitted by the user when your application triggers the collection manually, or automatically, when [automatic feedback surveys](../launch-monitor/automated-feedback-surveys.md) are enabled.
6 |
7 | ### Collected data
8 |
9 | The feedback, submitted by an user of your application will contain the following details:
10 |
11 | * The [user](user.md) and user's [company](company.md) IDs,
12 | * The [feature key](feature.md#feature-key) for which the feedback is provided,
13 | * The **score**, if configured to ask for one,
14 | * A **free-form message**, if configured to ask for one.
15 | * A **feedback request** ID if the feedback was submitted in response to an automatic request from Reflag.
16 |
17 | All feedback is collected in Reflag and used for various metrics.
18 |
19 | ### Next steps
20 |
21 | * Learn how to set up [automatic feedback surveys](../launch-monitor/automated-feedback-surveys.md) within Reflag UI.
22 |
23 |
```
--------------------------------------------------------------------------------
/product-handbook/feature-views.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Learn more about views in Reflag
3 | ---
4 |
5 | # Feature views
6 |
7 | ## What are views?
8 |
9 | Views group features in a single view to let you organize features as well as enable and customize Slack reporting and column configurations.
10 |
11 | ## Creating views
12 |
13 | You can create and manage views in the [App Settings](https://app.reflag.com/env-current/settings/app-stages). You can create new views, edit existing views, and enable weekly reporting to Slack.
14 |
15 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-12 at 15.16.42.png" alt=""><figcaption></figcaption></figure>
16 |
17 | ## Adding and removing flags to views
18 |
19 | To add a flag to a view, go to the [flag](https://app.reflag.com/env-current/features) you want to add to a view. In the right-hand sidebar, click on the + icon beside "Add to views" to add it to a view. You'll have the option to select an existing view or create a new one.
20 |
21 | You can remove a feature from a view simply by clicking on the X icon.
22 |
23 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-12 at 15.18.42.png" alt="Adding a feature to a feature view"><figcaption></figcaption></figure>
24 |
```
--------------------------------------------------------------------------------
/supported-languages/openfeature.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Reflag provides OpenFeature integration for use in browser (Web) and Node.js
3 | ---
4 |
5 | # OpenFeature
6 |
7 | ## What is OpenFeature? <a href="#what-is-the-react-sdk" id="what-is-the-react-sdk"></a>
8 |
9 | From [openfeature.dev](https://openfeature.dev):
10 |
11 | > OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool.
12 |
13 | Reflag provides OpenFeature integration for use in browser (Web) and Node.js.
14 |
15 | ## Getting started <a href="#getting-started" id="getting-started"></a>
16 |
17 | Reflag providers are [listed on openfeature.dev](https://openfeature.dev/ecosystem?instant_search%5Bquery%5D=reflag)
18 |
19 | Documentation:
20 |
21 | * [OpenFeature Node.js provider](https://github.com/reflagcom/javascript/blob/main/packages/openfeature-node-provider/README.md)
22 | * [OpenFeature Browser provider](https://github.com/reflagcom/javascript/tree/main/packages/openfeature-browser-provider)
23 |
24 | ## Further documentation <a href="#install-the-sdk" id="install-the-sdk"></a>
25 |
26 | [Learn about OpenFeature providers](https://openfeature.dev/docs/reference/concepts/provider) on the official docs
27 |
```
--------------------------------------------------------------------------------
/introduction/concepts/feedback.md:
--------------------------------------------------------------------------------
```markdown
1 | # Feedback
2 |
3 | ### Definition
4 |
5 | A feedback entity in Reflag is sent by the client when an user provides feedback within your application. You must be using Reflag SDKs to gain access to feedback collection functionality. Feedback can be submitted by the user when your application triggers the collection manually, or automatically, when [automatic feedback surveys](../../product-handbook/launch-monitor/automated-feedback-surveys.md) are enabled.
6 |
7 | ### Collected data
8 |
9 | The feedback, submitted by an user of your application will contain the following details:
10 |
11 | * The [user](user.md) and user's [company](company.md) IDs,
12 | * The [feature key](feature.md#feature-key) for which the feedback is provided,
13 | * The **score**, if configured to ask for one,
14 | * A **free-form message**, if configured to ask for one.
15 | * A **feedback request** ID if the feedback was submitted in response to an automatic request from Reflag.
16 |
17 | All feedback is collected in Reflag and used for various metrics including [STARS](broken-reference).
18 |
19 | ### Next steps
20 |
21 | * Learn how to set up [automatic feedback surveys](../../product-handbook/launch-monitor/automated-feedback-surveys.md) within Reflag UI.
22 |
23 |
```
--------------------------------------------------------------------------------
/integrations/github.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | Integrate GitHub to automatically check feature flag code references and
4 | receive automatic AI code clean-up pull requests
5 | ---
6 |
7 | # GitHub
8 |
9 | Using the integration for GitHub, Reflag does two things:
10 |
11 | * Automatically searches your repository for references to feature flags. This way you can know if a flag was cleaned up from your codebase or whether it's still being used. See how the clean-up guide uses this in [feature-clean-up-and-archival-beta](../product-handbook/feature-clean-up-and-archival-beta/ "mention").
12 | * Reflag can automatically clean up your code once a feature has been rolled out to everyone. See [ai-code-clean-up-beta.md](../product-handbook/feature-clean-up-and-archival-beta/ai-code-clean-up-beta.md "mention") for more information.
13 |
14 | {% hint style="info" %}
15 | GitHub integration is available on Pro and Enterprise [plans](https://reflag.com/pricing)
16 | {% endhint %}
17 |
18 | ## Connect to GitHub
19 |
20 | Connecting to GitHub happens at the Organization level. Go to [Organization settings](https://app.reflag.com/env-current/settings/org-integrations) and:
21 |
22 | 1. Click "Connect" for the GitHub integration.
23 | 2. You'll be taken to an authentication consent screen.
24 | 3. Once you've approved, you'll need to pick a repository.
25 |
```
--------------------------------------------------------------------------------
/product-handbook/data-residency.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Reflag on data residency
3 | ---
4 |
5 | # Data residency
6 |
7 | When you sign up with Reflag you automatically use our global infrastructure to guarantee low latency from your users' clients to our servers. 
8 |
9 | However, if you need your users' data to stay inside the EU you can contact us at [email protected] and request we change your data residency to EU only.
10 |
11 | By default, our SDKs connect to `front.reflag.com`. This points to our globally distributed edge servers and requests to this domain will be served generally by a server closest to the user. 
12 |
13 | However, if you're using the EU data residency, you must change the `apiBaseUrl` to `front-eu.reflag.com` when configuring the SDK to ensure the requests always land on one of our EU servers.
14 |
15 | Here's how you can set the host in our Browser SDK and Node SDK:
16 |
17 | ```ts
18 | // Browser SDK + Node SDK
19 | const reflagClient = new ReflagClient({
20 | publishableKey: "{YOUR_PUBLISHABLE_KEY}",
21 | apiBaseUrl: "https://front-eu.reflag.com",
22 | ...
23 | });
24 | ```
25 |
26 | And using the React SDK:
27 |
28 | ```tsx
29 | // React SDK
30 | import { ReflagProvider } from "@reflag/react-sdk";
31 |
32 | <ReflagProvider
33 | publishableKey="{YOUR_PUBLISHABLE_KEY}"
34 | company={{ id: "acme_inc" }}
35 | user={{ id: "john doe" }}
36 | apiBaseUrl="https://front-eu.reflag.com"
37 | >
38 | ...
39 | </ReflagProvider>
40 | ```
41 |
42 |
```
--------------------------------------------------------------------------------
/.gitbook/includes/sdks.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | title: SDKs
3 | ---
4 |
5 | <table data-view="cards" data-full-width="true"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>React</td><td><a href="../assets/react.svg">react.svg</a></td><td><a href="../../sdk/@reflag/react-sdk/">react-sdk</a></td></tr><tr><td>Vue.js</td><td><a href="../assets/vue-logo.svg">vue-logo.svg</a></td><td><a href="../../sdk/@reflag/vue-sdk/">vue-sdk</a></td></tr><tr><td>Client-side</td><td><a href="../assets/ts-js.svg">ts-js.svg</a></td><td><a href="../../sdk/@reflag/browser-sdk/">browser-sdk</a></td></tr><tr><td>Server-side</td><td><a href="../assets/node-js.svg">node-js.svg</a></td><td><a href="../../sdk/@reflag/node-sdk/">node-sdk</a></td></tr><tr><td>Next.js</td><td><a href="../assets/next-js.svg">next-js.svg</a></td><td><a href="../../supported-languages/next.js.md">next.js.md</a></td></tr><tr><td>Reflag supports OpenFeature</td><td><a href="../assets/openfeature.svg">openfeature.svg</a></td><td><a href="../../supported-languages/openfeature.md">openfeature.md</a></td></tr><tr><td>Don't use these languages or frameworks? Use our API</td><td><a href="../assets/api.svg">api.svg</a></td><td><a href="../../api/public-api/">public-api</a></td></tr></tbody></table>
6 |
```
--------------------------------------------------------------------------------
/.gitbook/includes/languages.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | title: Supported languages
3 | ---
4 |
5 | <table data-view="cards" data-full-width="true"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>React</td><td><a href="../assets/react.svg">react.svg</a></td><td><a href="../../sdk/@reflag/react-sdk/">react-sdk</a></td></tr><tr><td>Vue.js</td><td><a href="../assets/vue-logo.svg">vue-logo.svg</a></td><td><a href="../../sdk/@reflag/vue-sdk/">vue-sdk</a></td></tr><tr><td>Client-side</td><td><a href="../assets/ts-js.svg">ts-js.svg</a></td><td><a href="../../sdk/@reflag/browser-sdk/">browser-sdk</a></td></tr><tr><td>Server-side</td><td><a href="../assets/node-js.svg">node-js.svg</a></td><td><a href="../../sdk/@reflag/node-sdk/">node-sdk</a></td></tr><tr><td>Next.js</td><td><a href="../assets/next-js.svg">next-js.svg</a></td><td><a href="../../supported-languages/next.js.md">next.js.md</a></td></tr><tr><td>Reflag supports OpenFeature</td><td><a href="../assets/openfeature.svg">openfeature.svg</a></td><td><a href="../../supported-languages/openfeature.md">openfeature.md</a></td></tr><tr><td>Don't use these languages or frameworks? Use our API</td><td><a href="../assets/api.svg">api.svg</a></td><td><a href="../../api/public-api/">public-api</a></td></tr></tbody></table>
6 |
```
--------------------------------------------------------------------------------
/product-handbook/feature-entitlements/simple-role-based-entitlements.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Learn more about simple role-based entitlements in Reflag
3 | ---
4 |
5 | # Simple role-based entitlements
6 |
7 | If you need to enforce feature access at the company subscription level _**and**_ user role level (user permissions), you can combine your user role and permission services with Reflag.
8 |
9 | For example, let's say your "Export to CSV" feature is only available to customers on the "Business" or "Enterprise" plans _**and**_ only users with the "admin" role should be allowed to use it.
10 |
11 | If you have complex user permissions, you likely need to use a dedicated user authentication service with Role-Based Access Control (RBAC) support.
12 |
13 | If you have simple and static user permissions, like "admin" and "member", that don't change frequently, you may be able to hard code the access controls.
14 |
15 | ### Managing simple role-based user permissions
16 |
17 | Let's look at how to handle the simple use case with Reflag. 
18 |
19 | If you zoom out, this is what controlling feature access at the customer subscription level looks like.
20 |
21 | <figure><img src="../../.gitbook/assets/example 1 (1).png" alt=""><figcaption></figcaption></figure>
22 |
23 | To add simple user role controls to the mix, you can choose to hard code the user role check within the `isEnabled` check.
24 |
25 | <figure><img src="../../.gitbook/assets/example 2 (1).png" alt=""><figcaption></figcaption></figure>
26 |
27 |
28 |
29 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/segment.md:
--------------------------------------------------------------------------------
```markdown
1 | # Segment
2 |
3 | ### Definition
4 |
5 | A segment entity in Reflag is a dynamic collection of [companies](company.md). The dynamic nature of segments arise from the fact that segments use [filters](filter.md) to evaluate which companies are included in the segment.
6 |
7 | ### Filters
8 |
9 | Segment filters can be constructed using any combination of the following rules:
10 |
11 | * [company attributes](company.md#attributes), 
12 | * [user feature access](feature.md#access), 
13 | * [feature metrics](feature.md#metrics),
14 | * other segments
15 |
16 | {% hint style="info" %}
17 | Segments with a filter that uses `First Seen`, `Last Seen` company attribute rules or feature metric rules cannot be used in [targeting rules](targeting-rules.md). By extension, other segments depend on these segments, also cannot be used in targeting rules.
18 | {% endhint %}
19 |
20 | ### Environments
21 |
22 | All segments in Reflag are [app](app.md)-wide. This means that the same segment will share the same settings (including filters) across all the [environments](environment.md) in the app.
23 |
24 | It is up to you to populate the data in the environments you define in such a way that segments would pick up companies properly. Another option is to create separate segments for different environments.
25 |
26 | ### Next steps
27 |
28 | * Learn about [users](user.md), [filters](filter.md) and [targeting rules](targeting-rules.md).
29 | * Learn how to [create company segments](../creating-segments.md) within Reflag UI.
30 |
```
--------------------------------------------------------------------------------
/integrations/mixpanel.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | How Reflag integrates with Mixpanel to query analytics based on feature access
4 | filters
5 | ---
6 |
7 | # Mixpanel
8 |
9 | With the Mixpanel integration, you can attach feature access properties to users and groups on Mixpanel. This will enable you to query analytics based on feature access filters.
10 |
11 | ### Get available features from Reflag
12 |
13 | In this example, we're using the [Browser SDK](../sdk/@reflag/browser-sdk/):
14 |
15 | ```javascript
16 | //init
17 | const reflag = new ReflagBrowserSDK.ReflagClient({
18 | publishableKey: "pub_prod_5eS0G5hX4ZOpwoAw1CKTeP",
19 | user: {
20 | id: "u1234",
21 | name: "Rasmus Makwarth",
22 | },
23 | });
24 |
25 | //get features
26 | const features = reflag.getFeatures();
27 | ```
28 |
29 | This will return JSON with all available features for the authenticated user:
30 |
31 | ```json
32 | "features": {
33 | "export-to-csv": {
34 | "isEnabled": true,
35 | "key": "export-to-csv",
36 | "targetingVersion": 2
37 | },
38 | ...
39 | }
40 | ```
41 |
42 | ### Add as property on Mixpanel
43 |
44 | We can forward all features or pick certain features and send access state to Mixpanel. Here we send an array of features that the user has access to:
45 |
46 | ```javascript
47 | mixpanel.identify("u1234");
48 | mixpanel.people.set({
49 | $name: "Rasmus Makwarth",
50 | $features: ["export-to-csv"],
51 | });
52 | ```
53 |
54 | Which will look like this on Mixpanel:
55 |
56 | <figure><img src="../.gitbook/assets/CleanShot 2025-01-09 at 11 .11.54@2x (1).png" alt=""><figcaption></figcaption></figure>
57 |
58 | You may want to add the property to the user's group as well.
59 |
```
--------------------------------------------------------------------------------
/introduction/concepts/segment.md:
--------------------------------------------------------------------------------
```markdown
1 | # Segment
2 |
3 | ### Definition
4 |
5 | A segment entity in Reflag is a dynamic collection of [companies](company.md). The dynamic nature of segments arise from the fact that segments use [filters](filter.md) to evaluate which companies are included in the segment.
6 |
7 | ### Filters
8 |
9 | Segment filters can be constructed using any combination of the following rules:
10 |
11 | * [company attributes](company.md#attributes), 
12 | * [user feature access](feature.md#access), 
13 | * [feature metrics](feature.md#metrics),
14 | * other segments
15 |
16 | {% hint style="info" %}
17 | Segments with a filter that uses `First Seen`, `Last Seen` company attribute rules or feature metric rules cannot be used in [targeting rules](targeting-rules.md). By extension, other segments depend on these segments, also cannot be used in targeting rules.
18 | {% endhint %}
19 |
20 | ### Environments
21 |
22 | All segments in Reflag are [app](app.md)-wide. This means that the same segment will share the same settings (including filters) across all the [environments](environment.md) in the app.
23 |
24 | It is up to you to populate the data in the environments you define in such a way that segments would pick up companies properly. Another option is to create separate segments for different environments.
25 |
26 | ### Next steps
27 |
28 | * Learn about [users](user.md), [filters](filter.md) and [targeting rules](targeting-rules.md).
29 | * Learn how to [create company segments](../../product-handbook/feature-targeting-rules/creating-segments.md) within Reflag UI.
30 |
```
--------------------------------------------------------------------------------
/.gitbook/includes/untitled.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | title: Untitled
3 | ---
4 |
5 | <table data-view="cards" data-full-width="true"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><a href="../../integrations/slack.md"><strong>Slack</strong></a></td><td></td><td></td><td><a href="../assets/slack.svg">slack.svg</a></td></tr><tr><td><a href="../../integrations/linear.md"><strong>Linear</strong></a></td><td></td><td></td><td><a href="../assets/linear.svg">linear.svg</a></td></tr><tr><td><a href="../../integrations/segment.md"><strong>Segment</strong></a></td><td></td><td></td><td><a href="../assets/segment.svg">segment.svg</a></td></tr><tr><td><a href="../../integrations/datadog.md">Datadog</a></td><td></td><td></td><td><a href="../assets/datadog.svg">datadog.svg</a></td></tr><tr><td><a href="../../integrations/posthog.md"><strong>PostHog</strong></a></td><td></td><td></td><td><a href="../assets/posthog.svg">posthog.svg</a></td></tr><tr><td><a href="../../integrations/amplitude.md"><strong>Amplitude</strong></a></td><td></td><td></td><td><a href="../assets/amplitude.svg">amplitude.svg</a></td></tr><tr><td><a href="../../integrations/mixpanel.md"><strong>Mixpanel</strong></a></td><td></td><td></td><td><a href="../assets/mixpanel.svg">mixpanel.svg</a></td></tr><tr><td><a href="../../integrations/aws-s3.md"><strong>AWS S3</strong></a></td><td></td><td></td><td><a href="../assets/aws-s3.svg">aws-s3.svg</a></td></tr></tbody></table>
6 |
```
--------------------------------------------------------------------------------
/integrations/posthog.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | How Reflag integrates with PostHog to query analytics based on feature access
4 | filters
5 | ---
6 |
7 | # PostHog
8 |
9 | With the PostHog integration, you can attach feature access properties to users and groups on PostHog. This will enable you to query analytics based on feature access filters.
10 |
11 | ### Get available features from Reflag
12 |
13 | In this example, we're using the [@reflag/browser-sdk](../sdk/@reflag/browser-sdk/):
14 |
15 | ```javascript
16 | //init
17 | const reflag = new ReflagBrowserSDK.ReflagClient({
18 | publishableKey: "pub_prod_5eS0G5hX4ZOpwoAw1CKTeP",
19 | user: {
20 | id: "u1234",
21 | name: "Rasmus Makwarth",
22 | },
23 | });
24 |
25 | //get features
26 | const features = reflag.getFeatures();
27 | ```
28 |
29 | This will return JSON with all available features for the authenticated user:
30 |
31 | ```json
32 | "features": {
33 | "export-to-csv": {
34 | "isEnabled": true,
35 | "key": "export-to-csv",
36 | "targetingVersion": 2
37 | },
38 | ...
39 | }
40 | ```
41 |
42 | ### Add as property on PostHog
43 |
44 | We can forward all features or pick certain features and send access state to PostHog:
45 |
46 | <pre class="language-tsx"><code class="lang-tsx"><strong>posthog.identify("u1234", {
47 | </strong> name: "Rasmus Makwarth",
48 | features: {
49 | "export-to-csv": {
50 | isEnabled: true,
51 | },
52 | },
53 | });
54 | </code></pre>
55 |
56 | Which will look like this on PostHog:
57 |
58 | <figure><img src="../.gitbook/assets/CleanShot 2025-01-09 at 9 [email protected]" alt=""><figcaption></figcaption></figure>
59 |
60 | You may want to add the property to the user's group as well.
61 |
```
--------------------------------------------------------------------------------
/integrations/amplitude.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | How Reflag integrates with Amplitude to query analytics based on feature
4 | access filters
5 | ---
6 |
7 | # Amplitude
8 |
9 | With the Amplitude integration, you can attach feature access properties to users and groups on Amplitude. This will enable you to query analytics based on feature access filters.
10 |
11 | ### Get available features from Reflag
12 |
13 | In this example, we're using the [Browser SDK](../sdk/@reflag/browser-sdk/):
14 |
15 | ```javascript
16 | //init
17 | const reflag = new ReflagBrowserSDK.ReflagClient({
18 | publishableKey: "pub_prod_5eS0G5hX4ZOpwoAw1CKTeP",
19 | user: {
20 | id: "u1234",
21 | name: "Rasmus Makwarth",
22 | },
23 | });
24 |
25 | //get features
26 | const features = reflag.getFeatures();
27 | ```
28 |
29 | This will return JSON with all available features for the authenticated user:
30 |
31 | ```json
32 | "features": {
33 | "export-to-csv": {
34 | "isEnabled": true,
35 | "key": "export-to-csv",
36 | "targetingVersion": 2
37 | },
38 | ...
39 | }
40 | ```
41 |
42 | ### Add as property on Amplitude
43 |
44 | We can forward all features or pick certain features and send access state to Amplitude. Here we send an array of features that the user has access to:
45 |
46 | ```javascript
47 | amplitude.setUserId("u1234");
48 | const identifyEvent = new amplitude.Identify();
49 | identifyEvent.append("features", "export-to-csv");
50 | amplitude.identify(identifyEvent);
51 | ```
52 |
53 | Which will look like this on Amplitude:
54 |
55 | <figure><img src="../.gitbook/assets/CleanShot 2025-01-09 at 10 [email protected]" alt=""><figcaption></figcaption></figure>
56 |
57 | You may want to add the property to the user's group as well.
58 |
```
--------------------------------------------------------------------------------
/integrations/datadog.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | How Reflag integrates with Datadog to catch regressions on new feature
4 | releases
5 | ---
6 |
7 | # Datadog
8 |
9 | With the Datadog integration, you can enrich your RUM data with feature flag data. This will enable you to catch regressions on new feature releases.
10 |
11 | ### Get available features from Reflag
12 |
13 | In this example, we're using the [React SDK](../sdk/@reflag/browser-sdk/):
14 |
15 | ```javascript
16 | import { datadogRum } from "@datadog/browser-rum";
17 | import { useClient } from "@reflag/react-sdk";
18 |
19 | // Component to enhnance datadog RUM with flag checks
20 | function DatadogIntegration() {
21 | const client = useClient();
22 | useEffect(() => {
23 | return client?.on("check", (check) => {
24 | datadogRum.addFeatureFlagEvaluation(check.key, check.value);
25 | });
26 | }, [client]);
27 | return null;
28 | }
29 | ```
30 |
31 | Add the component inside the ReflagProvider:
32 |
33 | ```tsx
34 | function App() {
35 | return (
36 | <ReflagProvider>
37 | <DatadogIntegration /> // Add the component inside the <ReflagProvider>
38 | {children}
39 | </ReflagProvider>
40 | )
41 | }
42 | ```
43 |
44 | Which will look like this on Datadog:
45 |
46 | <figure><img src="../.gitbook/assets/feature-flag-list-rum-event.d9c1c876a34458edc70d1317efaec05b.png.avif" alt=""><figcaption></figcaption></figure>
47 |
48 | <figure><img src="../.gitbook/assets/rum-explorer-session-feature-flag-search.435802460fd607608ad5155f029da57b.png.avif" alt=""><figcaption></figcaption></figure>
49 |
50 | <figure><img src="../.gitbook/assets/rum-explorer-error-feature-flag-search.7b9f6c046db1de1c71d279c139f1508a.png.avif" alt=""><figcaption></figcaption></figure>
51 |
```
--------------------------------------------------------------------------------
/integrations/slack.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Integrate Slack to get notified about new feature changes and feedback
3 | ---
4 |
5 | # Slack
6 |
7 | With the integration for Slack, you can get notifications whenever a feature's access and/or stage changes and whenever an end-user submit feature feedback. You can also get a feature view report.
8 |
9 | ## Authenticate with Slack
10 |
11 | Authentication happens at the environment level. Once you've authenticated, all environments, apps and features can be connected to Slack.
12 |
13 | * Go to **Settings**
14 | * Select **Slack** under Environment.
15 |
16 | <figure><img src="../.gitbook/assets/slackDisconnected (1).png" alt=""><figcaption><p>Click "Connect to Slack" to authenticate</p></figcaption></figure>
17 |
18 | ## Choose default Slack channel
19 |
20 | You can set a default Slack channel for an app. This means that all features within the app will all inherit the default channel unless you overwrite it.
21 |
22 | * Go to Settings
23 | * Select **Slack** under **Environment: Production**
24 |
25 | Note: Slack notifications are only supported in the Production [environment](../product-handbook/concepts/environment.md).
26 |
27 | <figure><img src="../.gitbook/assets/slackConnected (1).png" alt=""><figcaption><p>Choose default Slack channel for this app's production environment</p></figcaption></figure>
28 |
29 |
30 |
31 | ## Available Slack notifications
32 |
33 | <table><thead><tr><th width="557">What</th><th>When</th></tr></thead><tbody><tr><td>Feature access or state changes</td><td>Real-time</td></tr><tr><td>Feature archive updates</td><td>Real-time</td></tr><tr><td>Feature feedback submissions</td><td>Real-time</td></tr></tbody></table>
34 |
35 |
```
--------------------------------------------------------------------------------
/.gitbook/assets/api.svg:
--------------------------------------------------------------------------------
```
1 | <svg width="512" height="289" viewBox="0 0 512 289" fill="none" xmlns="http://www.w3.org/2000/svg">
2 | <style>
3 | @media (prefers-color-scheme: dark) {
4 | path { fill: white; }
5 | }
6 | </style>
7 | <path d="M276.266 165.206V158.728H285.472V131.339H276.266V124.861H301.723V131.339H292.518V158.728H301.723V165.206H276.266Z" fill="#151519"/>
8 | <path d="M242.535 165.206V124.861H255.321C258.086 124.861 260.53 125.391 262.651 126.452C264.772 127.513 266.42 128.99 267.595 130.884C268.769 132.779 269.356 135.033 269.356 137.646C269.356 140.222 268.769 142.458 267.595 144.352C266.42 146.246 264.772 147.723 262.651 148.784C260.53 149.807 258.086 150.318 255.321 150.318H249.582V165.206H242.535ZM249.582 143.897H254.582C257.12 143.897 258.995 143.367 260.208 142.306C261.458 141.207 262.083 139.654 262.083 137.646C262.083 135.563 261.458 133.991 260.208 132.93C258.995 131.869 257.12 131.339 254.582 131.339H249.582V143.897Z" fill="#151519"/>
9 | <path d="M204.997 165.206L216.475 124.861H225.226L236.705 165.206H229.488L220.851 132.816L212.214 165.206H204.997ZM212.043 155.66L213.975 149.352H227.727L229.659 155.66H212.043Z" fill="#151519"/>
10 | <path fill-rule="evenodd" clip-rule="evenodd" d="M311.294 99H200.706C190.375 99 182 107.375 182 117.706V170.294C182 180.625 190.375 189 200.706 189H311.294C321.625 189 330 180.625 330 170.294V117.706C330 107.375 321.625 99 311.294 99ZM200.706 92C186.509 92 175 103.509 175 117.706V170.294C175 184.491 186.509 196 200.706 196H311.294C325.491 196 337 184.491 337 170.294V117.706C337 103.509 325.491 92 311.294 92H200.706Z" fill="#151519"/>
11 | </svg>
12 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/environment.md:
--------------------------------------------------------------------------------
```markdown
1 | # Environment
2 |
3 | ### Definition
4 |
5 | Environments, in Reflag, serve to fully segregate the collected data. In practice, this means that any data received by our [public API](../../api/public-api/public-api-reference.md) in the "_Production_" environment for example, will be completely different from the data collected in other environments. Specifically, this pertains to:
6 |
7 | * [Companies](company.md)' details that have been collected
8 | * [Users](user.md)' details
9 | * [Track events](event.md)
10 | * Collected [feedback](feedback.md)
11 | * [Feature events](feature-events.md)
12 |
13 | Aside from the collected data itself, there are a number of environment-specific settings and behaviors that can be configured on [features](feature.md) and [feature views](../feature-views.md). Additionally, any [targeting rules](targeting-rules.md) used within the app use environment-specific data.
14 |
15 | Each new [app](app.md), comes with three predefined environments: **Production**, **Staging** and **Development**.
16 |
17 | You can create or delete any environment at any time, except the Production environment. 
18 |
19 | {% hint style="danger" %}
20 | Deleted environments cannot be restored, and all collected data for that environment will essentially be lost. 
21 | {% endhint %}
22 |
23 | The main use case for environments is to test if data is coming through as expected and if features are set up correctly on local or staging environments before releasing to production.
24 |
25 | ### Next steps
26 |
27 | * Learn about [users](user.md) and [companies](company.md),
28 | * Learn how to [manage environments ](../creating-and-managing-apps/environments.md)within Reflag UI.
29 |
```
--------------------------------------------------------------------------------
/introduction/concepts/environment.md:
--------------------------------------------------------------------------------
```markdown
1 | # Environment
2 |
3 | ### Definition
4 |
5 | Environments, in Reflag, serve to fully segregate the collected data. In practice, this means that any data received by our [public API](../../api/api-reference.md) in the "_Production_" environment for example, will be completely different from the data collected in other environments. Specifically, this pertains to:
6 |
7 | * [Companies](company.md)' details that have been collected
8 | * [Users](user.md)' details
9 | * [Track events](event.md)
10 | * Collected [feedback](feedback.md)
11 | * [Feature events](feature-events.md)
12 |
13 | Aside from the collected data itself, there are a number of environment-specific settings and behaviors that can be configured on [features](feature.md) and [feature views](../../product-handbook/feature-views.md). Additionally, any [targeting rules](targeting-rules.md) used within the app use environment-specific data.
14 |
15 | Each new [app](app.md), comes with three predefined environments: **Production**, **Staging** and **Development**.
16 |
17 | You can create or delete any environment at any time, except the Production environment. 
18 |
19 | {% hint style="danger" %}
20 | Deleted environments cannot be restored, and all collected data for that environment will essentially be lost. 
21 | {% endhint %}
22 |
23 | The main use case for environments is to test if data is coming through as expected and if features are set up correctly on local or staging environments before releasing to production.
24 |
25 | ### Next steps
26 |
27 | * Learn about [users](user.md) and [companies](company.md),
28 | * Learn how to [manage environments](../../product-handbook/feature-targeting-rules/environments.md) within Reflag UI.
29 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/feature-events.md:
--------------------------------------------------------------------------------
```markdown
1 | # Flag events
2 |
3 | ### Definition
4 |
5 | Flag events in Reflag are generated automatically in some cases, and are sent by the client in others. Reflag uses these events to track [flag access](feature.md#access) and collects data usable to debug rule and context issues.
6 |
7 | ### Access evaluated
8 |
9 | This event is generated automatically on Reflag side when the client uses server-side feature evaluation (e.g. when using [@reflag/browser-sdk](../../sdk/@reflag/browser-sdk/) or [@reflag/react-sdk](../../sdk/@reflag/browser-sdk/)) or on client side when local evaluation is used (e.g. using local mode in [@reflag/node-sdk](../../sdk/@reflag/node-sdk/)).
10 |
11 | This events contains the following information:
12 |
13 | * The **actual context** that was used to evaluate the flag access,
14 | * Some details of the **flag** whose access rules were evaluated,
15 | * The **result** of the access evaluation, including **missing fields** that were expected in the [targeting rules](targeting-rules.md).
16 |
17 | ### Access checked
18 |
19 | This event is generated by all Reflag SDKs whenever the client code checks if a flag is enabled for a given context.
20 |
21 | This events contains the following information:
22 |
23 | * The **actual context** that was used to evaluate the flag access,
24 | * Some details of the **flag**,
25 | * The **result** of the access check.
26 |
27 | {% hint style="info" %}
28 | Reflag SDKs rate-limit generation of these events to avoid unnecessary traffic. Also, unknown flag evaluations and checks are also sent to Reflag facilitating debugging.
29 | {% endhint %}
30 |
31 | ### Next steps
32 |
33 | * Learn about [targeting rules](targeting-rules.md),
34 | * Learn how to [setup flag access rules](../feature-rollouts/feature-targeting-rules.md) within Reflag UI.
35 |
```
--------------------------------------------------------------------------------
/product-handbook/product-overview.md:
--------------------------------------------------------------------------------
```markdown
1 | # Product overview
2 |
3 | ## Flags
4 |
5 | The Flags tab of Reflag is where you create and manage your flags.
6 |
7 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-12 at 12.30.38.png" alt=""><figcaption></figcaption></figure>
8 |
9 | ## Flag page
10 |
11 | This is where you create and manage feature flags, set access rules, remote config, and monitor your feature launch. 
12 |
13 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-02 at 17.10.36 (2).png" alt="Feature page with rollout targeting rules"><figcaption></figcaption></figure>
14 |
15 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-02 at 17.11.21 (1).png" alt=""><figcaption></figcaption></figure>
16 |
17 | <figure><img src="../.gitbook/assets/Monitor.png" alt=""><figcaption></figcaption></figure>
18 |
19 | ## Companies
20 |
21 | The Companies tab lists all of the companies that use your application. You can used advanced filters to filter the companies list and create saved segments.
22 |
23 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-02 at 17.13.15 (1).png" alt=""><figcaption></figcaption></figure>
24 |
25 | ## Event log
26 |
27 | The Event log tab shows you a log of recent events as well as a list of all the distinct events being tracked in Reflag.
28 |
29 | <figure><img src="../.gitbook/assets/Debugger-min (2).png" alt="Debugger page"><figcaption></figcaption></figure>
30 |
31 | ## Settings
32 |
33 | The Settings tab is where you manage billing, [users](team-permissions.md), [integrations](broken-reference), [feature views](feature-views.md), [company segments](creating-segments.md), [environments](creating-and-managing-apps/environments.md), data exports, and more.
34 |
35 | <figure><img src="../.gitbook/assets/Settings-min (1).png" alt="Global settings page"><figcaption></figcaption></figure>
36 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/user.md:
--------------------------------------------------------------------------------
```markdown
1 | # User
2 |
3 | ### Definition
4 |
5 | An **user** entity in Reflag is used to store the details of an user that interacted with your application. Users are normally part of one or more [companies](company.md). It is mandatory that the user [be part of a company](company.md#associating-with-users), otherwise user's interactions are not taken into account.
6 |
7 | ### Attributes
8 |
9 | An user entity is essentially a collection of **attributes**. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each user must have: `ID`, and three special attributes Reflag uses in its UI for convenience: `email`, `name` and `avatar`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Reflag manages a set of computed attributes when you send data to Reflag:
12 |
13 | * `First seen` and `Last seen` denote the first and last time the company-related interactions have been sent to Reflag,
14 | * `Event count` is updated any time there is a new [event](event.md) received referencing the user.
15 |
16 | {% hint style="info" %}
17 | In Segment terminology, users can be thought of as acting as an [Identify](https://segment.com/docs/connections/spec/identify/) call. User attributes can be thought of as [User traits](https://segment.com/docs/connections/spec/identify/#custom-traits).
18 | {% endhint %}
19 |
20 | {% hint style="warning" %}
21 | Do not include PII data when sending in user attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
22 | {% endhint %}
23 |
24 | ### Next steps
25 |
26 | * Learn about [events](event.md) and [feedback](feedback.md),
27 | * Learn how to [define feature access rules](../feature-rollouts/feature-targeting-rules.md) using user attributes within Reflag UI.
28 |
```
--------------------------------------------------------------------------------
/introduction/concepts/feature-events.md:
--------------------------------------------------------------------------------
```markdown
1 | # Feature events
2 |
3 | ### Definition
4 |
5 | Feature events in Reflag are generated automatically in some cases, and are sent by the client in others. Reflag uses these events to track [feature access](feature.md#access) and collects data usable to debug rule and context issues.
6 |
7 | ### Access evaluated
8 |
9 | This event is generated automatically on Reflag side when the client uses server-side feature evaluation (e.g. when using [@reflag/browser-sdk](../../sdk/@reflag/browser-sdk/) or [@reflag/react-sdk](../../sdk/@reflag/react-sdk/)) or on client side when local evaluation is used (e.g. using local mode in [@reflag/node-sdk](../../sdk/@reflag/node-sdk/)).
10 |
11 | This events contains the following information:
12 |
13 | * The **actual context** that was used to evaluate the feature access,
14 | * Some details of the **feature** whose access rules were evaluated,
15 | * The **result** of the access evaluation, including **missing fields** that were expected in the [targeting rules](targeting-rules.md).
16 |
17 | ### Access checked
18 |
19 | This event is generated by all Reflag SDKs whenever the client code checks if a feature is enabled for a given context.
20 |
21 | This events contains the following information:
22 |
23 | * The **actual context** that was used to evaluate the feature access,
24 | * Some details of the **feature**,
25 | * The **result** of the access check.
26 |
27 | {% hint style="info" %}
28 | Reflag SDKs rate-limit generation of these events to avoid unnecessary traffic. Also, unknown features' evaluations and checks are also sent to Reflag facilitating debugging.
29 | {% endhint %}
30 |
31 | ### Next steps
32 |
33 | * Learn about [targeting rules](targeting-rules.md),
34 | * Learn how to [setup feature access rules](../../product-handbook/feature-rollouts/feature-targeting-rules.md) within Reflag UI.
35 |
```
--------------------------------------------------------------------------------
/introduction/concepts/user.md:
--------------------------------------------------------------------------------
```markdown
1 | # User
2 |
3 | ### Definition
4 |
5 | An **user** entity in Reflag is used to store the details of an user that interacted with your application. Users are normally part of one or more [companies](company.md). It is mandatory that the user [be part of a company](company.md#associating-with-users), otherwise user's interactions are not taken into account.
6 |
7 | ### Attributes
8 |
9 | An user entity is essentially a collection of **attributes**. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each user must have: `ID`, and three special attributes Reflag uses in its UI for convenience: `email`, `name` and `avatar`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Reflag manages a set of computed attributes when you send data to Reflag:
12 |
13 | * `First seen` and `Last seen` denote the first and last time the company-related interactions have been sent to Reflag,
14 | * `Event count` is updated any time there is a new [event](event.md) received referencing the user.
15 |
16 | {% hint style="info" %}
17 | In Segment terminology, users can be thought of as acting as an [Identify](https://segment.com/docs/connections/spec/identify/) call. User attributes can be thought of as [User traits](https://segment.com/docs/connections/spec/identify/#custom-traits).
18 | {% endhint %}
19 |
20 | {% hint style="warning" %}
21 | Do not include PII data when sending in user attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
22 | {% endhint %}
23 |
24 | ### Next steps
25 |
26 | * Learn about [events](event.md) and [feedback](feedback.md),
27 | * Learn how to [define feature access rules](../../product-handbook/feature-rollouts/feature-targeting-rules.md) using user attributes within Reflag UI.
28 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/feature.md:
--------------------------------------------------------------------------------
```markdown
1 | # Flag
2 |
3 | ### Definition
4 |
5 | A **flag** is an entity in Reflag that is used manage a "_feature in your product_". This refers to releasing the feature, manage access, configure, track adoption, gather feedback, and etc.
6 |
7 | Flags can be organized into hierarchies (having other flags as parent) and grouped into [views](feature-view.md), for easy reporting.
8 |
9 | ### Flag key
10 |
11 | Each flag has an unique key and some basic details such as name and description, adoption rules, feedback configuration and other.
12 |
13 | {% hint style="warning" %}
14 | Flag keys are unique across your [app](app.md). They cannot be edited after the flag is created. The flag key is _also_ is used for tracking feature adoption and getting feedback.
15 | {% endhint %}
16 |
17 | The following entities are associated with a flag through its key:
18 |
19 | * [Track event](event.md),
20 | * [Feature events](feature-events.md),
21 | * [Feedback](feedback.md).
22 |
23 | ### Access
24 |
25 | Each flag in Reflag comes with a set of access [targeting rules](targeting-rules.md) that are evaluated against the context of the user of your application. Access is evaluated each time the rules change of the context changes. Reflag SDKs transparently deal with evaluation, caching and refreshing of access status of the user of your application. 
26 |
27 | Flag access can also be used within Reflag itself as a [filter](filter.md#feature-access-filter) consumed by other entities.
28 |
29 | ### Metrics
30 |
31 | Flag metrics are a set of values that are calculated for each company that is using the feature. These metrics include `Average feedback score`, `First and Last used` dates and others.
32 |
33 | Flag metrics are used within the Reflag UI in various places but can also serve as values for [filters](filter.md#company-feature-metrics) consumed by other entities.
34 |
35 | ### Next steps
36 |
37 | * Learn about [views](feature-view.md), [track](event.md) and [events](feature-events.md),
38 | * Learn how to [create your first feature](../../) within Reflag UI.
39 |
```
--------------------------------------------------------------------------------
/product-handbook/feature-targeting-rules/creating-segments.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Learn more about segments in Reflag
3 | ---
4 |
5 | # Creating segments
6 |
7 | ## What's a segment?
8 |
9 | Segments are reusable lists of companies created based off one of more of the following:
10 |
11 | * [Company attributes](../../introduction/concepts/company.md#attributes) 
12 | * Feature access
13 | * Feature metrics
14 | * Feature feedback
15 |
16 | Company segments can be used as access rule for managing feature access.
17 |
18 | ## Getting started <a href="#get-started" id="get-started"></a>
19 |
20 | * Go to the `Companies` page on the sidebar
21 | * Click on the `Add filter +` menu item to build your segment conditions
22 |
23 | ## Set segment conditions
24 |
25 | Each segment is created using a set of conditions. You can add as many segmentation conditions as you’d like. 
26 |
27 | ### Conditions
28 |
29 | There are 4 types of conditions:
30 |
31 | * `Company attribute`
32 | * `Company ID`
33 | * `Company name`
34 | * `any custom attributes`
35 | * `Feature access` 
36 | * `isEnabled`
37 | * `Feature metric` 
38 | * `STARS`
39 | * `Frequency`
40 | * `Satisfaction`
41 | * `Event count`
42 | * `First used`
43 | * `Last used`
44 | * `Segment` 
45 | * `in Segment`
46 | * `not in Segment`
47 |
48 | <figure><img src="../../.gitbook/assets/Set segment conditions-min.png" alt="Using feature filters to create segments"><figcaption></figcaption></figure>
49 |
50 | ### **Operators**
51 |
52 | * Any
53 | * `Is`
54 | * `Is not`
55 | * `Has any value`
56 | * `Has no value`
57 | * Text
58 | * `Contains`
59 | * `Does not contain`
60 | * List
61 | * `Is any of`
62 | * `Is not any of`
63 | * Number
64 | * `Less than`
65 | * `Greater than`
66 | * Boolean
67 | * `Is true`
68 | * `Is false`
69 | * Date
70 | * `Less than X days ago`
71 | * `More than X days ago`
72 | * Feature access
73 | * `Is enabled`
74 | * `Is not enabled`
75 | * Segment
76 | * `In segment`
77 | * `Not in segment`
78 |
79 | ## Save the segment
80 |
81 | After adding any applicable conditions, you can save the segment. You can create as many segments as you need.
82 |
83 | <figure><img src="../../.gitbook/assets/Save the segment-min.png" alt="Saving a segment"><figcaption></figcaption></figure>
84 |
```
--------------------------------------------------------------------------------
/product-handbook/type-safety.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Reflag offers type safety which reduces errors and frustation
3 | ---
4 |
5 | # Type safety
6 |
7 | {% embed url="https://www.youtube.com/watch?v=2ay2sc9g6Oc" %}
8 |
9 | Type safety in Reflag ensures that flag key typos become build errors. This guarantees that if you try to use a non-existent flag key, you'll receive a type error, preventing potential runtime errors and improving code reliability. For remote config, it also ensures that the shape of the payload defined on Reflag matches what your code expects.
10 |
11 | Use the Reflag CLI to generate flag types from their definition in Reflag. Once flag types have been generated they are automatically picked up by TypeScript.
12 |
13 | It's recommended that you do not check in the flag types, but instead generate them in your build process and on your local development machines.
14 |
15 | ## Set up type safety for flags
16 |
17 | 1. Install the Reflag CLI and set up your repository
18 |
19 | ```
20 | npm install --save-dev @reflag/cli
21 | npx reflag init
22 | ```
23 | 2. Generate the types locally
24 |
25 | ```
26 | npx reflag types generate
27 | ```
28 | 3. Add the generated files to `.gitignore`
29 |
30 | ```
31 | echo "gen/flags.d.ts" >> .gitignore
32 | ```
33 | 4. Retrieve an [API Key](http://app.reflag.com/env-current/settings/org-api-access) for your build system
34 | 5. Set up your build system to run the Reflag CLI to generate types (use the `--api-key` option or specify the API key in the `REFLAG_API_KEY` environment variable)
35 |
36 | ```
37 | npx reflag apps list --api-key $REFLAG_API_KEY
38 | ```
39 |
40 | Example CI workflow:
41 |
42 | ```yaml
43 | # GitHub Actions example
44 | - name: Generate types
45 | run: npx reflag flags types --api-key ${{ secrets.REFLAG_API_KEY }}
46 |
47 | # GitHub Actions example (using environment):
48 | - name: Generate types (environment)
49 | run: npx reflag flags types
50 | env:
51 | REFLAG_API_KEY: ${{ secrets.REFLAG_CI_API_KEY }}
52 | ```
53 |
54 | There's further guidance and examples of using [Reflag CLI in CI/CD pipelines](https://docs.reflag.com/api/cli#using-in-ci-cd-pipelines-beta).
55 |
```
--------------------------------------------------------------------------------
/product-handbook/team-permissions.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Invite, remove and manage roles for your team members
3 | ---
4 |
5 | # Team permissions
6 |
7 | ## Team management basics
8 |
9 | The Team Management page in your Reflag organization provides essential features for overseeing your team:
10 |
11 | * **Invitations**: Easily copy the secret invite link to allow new members to join your organization. Admins can refresh the invite link as needed.
12 | * **User listing**: View the complete list of current organization members. The table displays each user's details, including their join date and role.
13 |
14 | Team member roles can be changed by selecting them from the dropdown. Additionally, any member can be removed from the organization by clicking the "_delete_" icon situated next to the role selector.
15 |
16 | <figure><img src="../.gitbook/assets/https___content.gitbook.com_content_pgXAy2Cgsm5pON9oJ06m_blobs_6wGbrQlJPE4JllBuIhla_image (1).png" alt=""><figcaption><p>Team management page</p></figcaption></figure>
17 |
18 | ## Roles and permissions
19 |
20 | {% hint style="info" %}
21 | Team roles are only available on **Pro** and **Enterprise** plans. In organizations not on these plans, roles are not enforced, and every team member is implicitly an **Admin**.
22 | {% endhint %}
23 |
24 | * **Viewer**: Can view content within your organization, but cannot make any changes.
25 | * **Writer (except production)**: Can create and update features, feature views, and manage feedback. Can modify non-production targeting for features and remote configs. Cannot alter organization-wide settings and most app settings.
26 | * **Writer**: Can do everything that **Writer (except production)** can, plus production targeting updates and segment management.
27 | * **Admin**: Full access to all features and settings, including managing other members' roles and removing users from the organization.
28 |
29 | {% hint style="info" %}
30 | **Note**: All new users invited to the organization will be assigned the **Viewer** role by default, ensuring they have appropriate access without making any changes.
31 | {% endhint %}
32 |
```
--------------------------------------------------------------------------------
/product-handbook/creating-segments.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Learn more about segments in Reflag
3 | ---
4 |
5 | # Creating segments
6 |
7 | ## What's a segment?
8 |
9 | Segments are reusable lists of companies created based off one of more of the following:
10 |
11 | * [Company attributes](concepts/company.md#attributes) 
12 | * Flag access
13 | * Flag metrics
14 | * Feature feedback
15 |
16 | Company segments can be used as access rule for managing flag access.
17 |
18 | ## Getting started <a href="#get-started" id="get-started"></a>
19 |
20 | * Go to the `Companies` page on the sidebar
21 | * Click on the `Add filter +` menu item to build your segment conditions
22 |
23 | ## Set segment conditions
24 |
25 | Each segment is created using a set of conditions. You can add as many segmentation conditions as you’d like. 
26 |
27 | ### Conditions
28 |
29 | There are 4 types of conditions:
30 |
31 | * `Company attribute`
32 | * `Company ID`
33 | * `First seen` 
34 | * `Last seen` 
35 | * `any custom attributes`
36 | * `Flag access` 
37 | * `is enabled`
38 | * `is not enabled`  
39 | * `Flag metric` 
40 | * `Track count` 
41 | * `Exposure count`
42 | * `First track`
43 | * `Last track`  
44 | * `Segment` 
45 | * `in Segment`
46 | * `not in Segment`
47 |
48 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-12 at 15.13.45.png" alt="Using feature filters to create segments"><figcaption></figcaption></figure>
49 |
50 | ### **Operators**
51 |
52 | * Any
53 | * `Is`
54 | * `Is not`
55 | * `Has any value`
56 | * `Has no value`
57 | * Text
58 | * `Contains`
59 | * `Does not contain`
60 | * List
61 | * `Is any of`
62 | * `Is not any of`
63 | * Number
64 | * `Less than`
65 | * `Greater than`
66 | * Boolean
67 | * `Is true`
68 | * `Is false`
69 | * Date
70 | * `Less than X days ago`
71 | * `More than X days ago`
72 | * `Before date X`  
73 | * `After date X`  
74 | * Flag access
75 | * `Is enabled`
76 | * `Is not enabled`
77 | * Segment
78 | * `In segment`
79 | * `Not in segment`
80 |
81 | ## Save the segment
82 |
83 | After adding any applicable conditions, you can save the segment. You can create as many segments as you need.
84 |
85 | <figure><img src="../.gitbook/assets/Screenshot 2025-09-12 at 15.14.43.png" alt="Saving a segment"><figcaption></figcaption></figure>
86 |
```
--------------------------------------------------------------------------------
/introduction/concepts/feature.md:
--------------------------------------------------------------------------------
```markdown
1 | # Feature
2 |
3 | ### Definition
4 |
5 | A **feature** is an entity in Reflag that is used manage a "_feature in your product_". This refers to releasing the feature, manage access, configure, track adoption, gather feedback, and etc.
6 |
7 | Features can be organized into hierarchies (having other features as parent) and grouped into [feature views](feature-view.md), for easy reporting.
8 |
9 | ### Feature key
10 |
11 | Each feature has an unique feature key and some basic details such as name and description, adoption rules, feedback configuration and other.
12 |
13 | {% hint style="warning" %}
14 | Feature keys are unique across your [app](app.md). They cannot be edited after the feature is created. You can think of the feature key as a **flag key** that _also_ is used for tracking feature adoption and getting feedback.
15 | {% endhint %}
16 |
17 | The following entities are associated with a feature through its key:
18 |
19 | * [Track event](event.md),
20 | * [Feature events](feature-events.md),
21 | * [Feedback](feedback.md).
22 |
23 | ### Access
24 |
25 | Each feature in Reflag comes with a set of access [targeting rules](targeting-rules.md) that are evaluated against the context of the user of your application. Access is evaluated each time the rules change of the context changes. Reflag SDKs transparently deal with evaluation, caching and refreshing of access status of the user of your application. 
26 |
27 | Feature access can also be used within Reflag itself as a [filter](filter.md#feature-access-filter) consumed by other entities.
28 |
29 | ### Metrics
30 |
31 | Feature metrics are a set of values that are calculated for each company that is using the feature. These metrics include `Average feedback score`, `STARS state`, `First and Last used` dates and others.
32 |
33 | Feature metrics are used within the Reflag UI in various places but can also serve as values for [filters](filter.md#company-feature-metrics) consumed by other entities.
34 |
35 | ### Next steps
36 |
37 | * Learn about [feature views](feature-view.md), [track](event.md) and [feature events](feature-events.md),
38 | * Learn how to [create your first feature](broken-reference) within Reflag UI.
39 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/targeting-rules.md:
--------------------------------------------------------------------------------
```markdown
1 | # Targeting rules
2 |
3 | ### Definition
4 |
5 | Targeting rules are entities used in Reflag to describe the target audience of a given [feature](feature.md). The target audience refers to the users that can interact with the feature within your application. Additionally, each targeting rule contains a value that is used for the target audience.
6 |
7 | ### Filters
8 |
9 | Targeting rules are essentially a collection [filters](filter.md) that are matched against a specific evaluation context. The first rule with a filter matching the context is selected, and its value used as result. In the case of feature access it can either be `true` , indicating that the feature is accessible. If no rules match the context, a value of `false` is used — feature not accessible.
10 |
11 | ### Evaluation context
12 |
13 | The evaluation context refers simply to a collection of **key** — **value** pairs that are passed to the rules' filters. Reflag expects the evaluation context to contains the following data:
14 |
15 | * User's `ID` as a minimum, 
16 | * Any other [user attributes](user.md#attributes) that might be used by the filters in the rules,
17 | * Company's `ID` is necessary in the vast majority of cases, though it's not mandatory,
18 | * Any other [company attributes](company.md#attributes) that might be used by the filters in the rules,
19 | * A collection of "_**other**_" attributes that can be used by the feature access targeting rules.
20 |
21 | The exact structure of the data will vary by the SDK in use.
22 |
23 | ### Missing context fields
24 |
25 | During the evaluation of targeting rules against a context it might happen that context is missing some details that the rules require. In such cases, those rules are discarded from evaluation as it would be unsafe to do otherwise.
26 |
27 | Reflag reports these missing context fields using [feature events](feature-events.md). Reflag SDKs will also generate warnings in these cases making it easy to find these situations in your application.
28 |
29 | ### Next steps
30 |
31 | * Learn about [filters](filter.md),
32 | * Learn how to [setup feature access rules](../feature-rollouts/feature-targeting-rules.md) within Reflag UI.
33 |
34 |
```
--------------------------------------------------------------------------------
/introduction/concepts/targeting-rules.md:
--------------------------------------------------------------------------------
```markdown
1 | # Targeting rules
2 |
3 | ### Definition
4 |
5 | Targeting rules are entities used in Reflag to describe the target audience of a given [feature](feature.md). The target audience refers to the users that can interact with the feature within your application. Additionally, each targeting rule contains a value that is used for the target audience.
6 |
7 | ### Filters
8 |
9 | Targeting rules are essentially a collection [filters](filter.md) that are matched against a specific evaluation context. The first rule with a filter matching the context is selected, and its value used as result. In the case of feature access it can either be `true` , indicating that the feature is accessible. If no rules match the context, a value of `false` is used — feature not accessible.
10 |
11 | ### Evaluation context
12 |
13 | The evaluation context refers simply to a collection of **key** — **value** pairs that are passed to the rules' filters. Reflag expects the evaluation context to contains the following data:
14 |
15 | * User's `ID` as a minimum, 
16 | * Any other [user attributes](user.md#attributes) that might be used by the filters in the rules,
17 | * Company's `ID` is necessary in the vast majority of cases, though it's not mandatory,
18 | * Any other [company attributes](company.md#attributes) that might be used by the filters in the rules,
19 | * A collection of "_**other**_" attributes that can be used by the feature access targeting rules.
20 |
21 | The exact structure of the data will vary by the SDK in use.
22 |
23 | ### Missing context fields
24 |
25 | During the evaluation of targeting rules against a context it might happen that context is missing some details that the rules require. In such cases, those rules are discarded from evaluation as it would be unsafe to do otherwise.
26 |
27 | Reflag reports these missing context fields using [feature events](feature-events.md). Reflag SDKs will also generate warnings in these cases making it easy to find these situations in your application.
28 |
29 | ### Next steps
30 |
31 | * Learn about [filters](filter.md),
32 | * Learn how to [setup feature access rules](../../product-handbook/feature-rollouts/feature-targeting-rules.md) within Reflag UI.
33 |
34 |
```
--------------------------------------------------------------------------------
/guides/use-reflag-in-your-cli.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: High-level guide to flagging features in your CLI
3 | icon: rectangle-terminal
4 | ---
5 |
6 | # Use Reflag in your CLI
7 |
8 | ### If you use API token for auth 
9 |
10 | First, create an endpoint in your backend for the CLI to call:
11 |
12 | ```
13 | POST /get-flags
14 | Authorization: Bearer <APIKEY>
15 | ```
16 |
17 | The endpoint will take the API key and use it to look up the associated user.
18 |
19 | Then, use the [public-api-reference.md](../api/public-api/public-api-reference.md "mention") to get enabled flags for the authenticated user. Return the flags to the CLI:
20 |
21 | ```
22 | {
23 | flags: ['flag1', 'flag2']
24 | }
25 | ```
26 |
27 | Finally, check for access with a simple:
28 |
29 | ```tsx
30 | /function isFlagEnabled(flag: string) {
31 | return flags.contains('myflag');
32 | }
33 | ```
34 |
35 | ### If you use API token for auth AND Node.js
36 |
37 | First, create an endpoint in your backend for the CLI to call:
38 |
39 | ```
40 | POST /get-flags
41 | Authorization: Bearer <APIKEY>
42 | ```
43 |
44 | The endpoint will take the API key and use it to look up the associated user.
45 |
46 | Use the [node-sdk](../sdk/@reflag/node-sdk/ "mention") get enabled flags for the authenticated user.
47 |
48 | ```jsx
49 | import { ReflagClient } from "@reflag/node-sdk";
50 |
51 | // configure the client
52 | const boundClient = reflagClient.bindClient({
53 | user: {
54 | id: "c1_u1",
55 | name: "John Doe"
56 | },
57 | company: {
58 | id: "c1",
59 | name: "Acme, Inc."
60 | },
61 | });
62 |
63 | // get flags
64 | const flags = boundClient.getFlags();
65 | ```
66 |
67 | Finally, check for access with a simple:
68 |
69 | ```tsx
70 | if(flags['myflag'].isEnabled) {
71 | //feature access
72 | }
73 | ```
74 |
75 |
76 |
77 | ### If you use OAuth for auth
78 |
79 | Use [node-sdk](../sdk/@reflag/node-sdk/ "mention") or [public-api-reference.md](../api/public-api/public-api-reference.md "mention") to get flags for the authenticated user.
80 |
81 | In Node, configure the SDK like so:
82 |
83 | ```jsx
84 | import { ReflagClient } from "@reflag/node-sdk";
85 |
86 | // configure the client
87 | const boundClient = reflagClient.bindClient({
88 | user: {
89 | id: "c1_u1",
90 | name: "John Doe"
91 | },
92 | company: {
93 | id: "c1",
94 | name: "Acme, Inc."
95 | },
96 | });
97 | ```
98 |
99 | Check access for individual flag:
100 |
101 | ```jsx
102 | const { isEnabled } = boundClient.getFlag("myflag");
103 |
104 | if (isEnabled) {
105 | //feature access
106 | }
107 | ```
108 |
109 | Or get all flags:
110 |
111 | ```jsx
112 | const flags = boundClient.getFlags();
113 | ```
114 |
115 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/event.md:
--------------------------------------------------------------------------------
```markdown
1 | # Track event
2 |
3 | ### Definition
4 |
5 | A track event in Reflag is sent by the client when an user interacts with a feature within your application. Reflag uses these events to [track feature adoption](feature.md#metrics) or launch [feedback surveys](../launch-monitor/automated-feedback-surveys.md). In most cases, you don't need to create custom track events as you'll just use the [feature key](feature.md#feature-key) instead.
6 |
7 | ### Attributes
8 |
9 | An event entity is essentially a collection of **attributes** associated with an event name or feature key. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each event must have: `userId`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Event attributes are useful mainly when setting up event-based features which can be configured to match specific events based on these attributes. Another use case applies to automatic feedback surveys which can be set to trigger on a specific event based on a combination of attributes.
12 |
13 | Reflag manages a set of computed attributes when you send data to Reflag:
14 |
15 | * `First seen`**,** `Last seen` and `Event count` of the [users](user.md#attributes) and [companies](company.md#attributes),
16 | * `First used`**,** `Last used` and `Event count` of the [companies](company.md#attributes) relative to the [feature](feature.md#metrics) that matched the event.
17 |
18 | {% hint style="info" %}
19 | In Segment terminology, these events can be thought of as acting as a [Track](https://segment.com/docs/connections/spec/track/) call. Event attributes can be thought of as [Event traits](https://segment.com/docs/connections/spec/track/#sending-traits-in-a-track-call---destination-actions).
20 | {% endhint %}
21 |
22 | {% hint style="warning" %}
23 | Do not include PII data when sending in event attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
24 | {% endhint %}
25 |
26 | ### Next steps
27 |
28 | * Learn about [feedback](feedback.md) and setting up [automatic feedback surveys](../launch-monitor/automated-feedback-surveys.md) within Reflag UI,
29 | * Learn how to [create an event-based feature](feature-events.md) using user attributes within Reflag UI.
30 |
```
--------------------------------------------------------------------------------
/product-handbook/self-opt-in.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How to create a beta feature self opt-in page in React with Reflag
3 | icon: browser
4 | ---
5 |
6 | # Create a beta feature opt-in page
7 |
8 | Creating a page where users can opt into certain beta/experimental features is straight forward with Reflag and the Reflag React SDK.
9 |
10 | The basic concept is to set an attribute on the user/company which denotes that the user has self opted into a specific feature, for example `optin-<flagKey> = true.` Updating an attribute is very simple from the SDK. Then use that attribute to control who has access to the feature by updating the flag access rules such that users/companies with the attribute `optin-<flagKey>=true` will have access to the feature.
11 |
12 | ## Step by step guide
13 |
14 | Here's a step by step guide:
15 |
16 | 1. Select a feature to let people self opt-into.
17 | 2. Add the rule: `optin-<flagKey> IS TRUE` to the rules section for all the environments. Replace `<flagKey>` with the actual flag key of the flag.
18 | 3. Use the following React component to let users self opt-in to specific features:
19 |
20 | ```tsx
21 | import { useUpdateUser, useFlag, TypedFlags } from "@reflag/react-sdk";
22 | import { useState } from "react";
23 |
24 | function FeatureOptIn({
25 | flagKey,
26 | featureName,
27 | }: {
28 | flagKey: TypedFlags;
29 | featureName: string;
30 | }) {
31 | const updateUser = useUpdateUser();
32 | const [sendingUpdate, setSendingUpdate] = useState(false);
33 | const { isEnabled } = useFlag(flagKey);
34 |
35 | return (
36 | <div>
37 | <label htmlFor="huddlesOptIn">Opt-in to {featureName} feature</label>
38 | <input
39 | disabled={sendingUpdate}
40 | id="huddlesOptIn"
41 | type="checkbox"
42 | checked={isEnabled}
43 | onChange={() => {
44 | setSendingUpdate(true);
45 | updateUser({
46 | [`optin-${flagKey}`]: isEnabled ? "false" : "true",
47 | }).then(() => {
48 | setSendingUpdate(false);
49 | });
50 | }}
51 | />
52 | </div>
53 | );
54 | }
55 | ```
56 |
57 | ### How it works
58 |
59 | The React component above uses [remote attributes](https://reflag.com/changelog/introducing-remote-attributes) to ensure that any flag you've enabled stays enabled between sessions.
60 |
61 | ### Next steps
62 |
63 | - Learn how to manage who has access, modify the [Targeting rules](feature-rollouts/feature-targeting-rules.md) in the UI.
64 |
```
--------------------------------------------------------------------------------
/introduction/concepts/event.md:
--------------------------------------------------------------------------------
```markdown
1 | # Track event
2 |
3 | ### Definition
4 |
5 | A track event in Reflag is sent by the client when an user interacts with a feature within your application. Reflag uses these events to [track feature adoption](feature.md#metrics) or launch [feedback surveys](../../product-handbook/launch-monitor/automated-feedback-surveys.md). In most cases, you don't need to create custom track events as you'll just use the [feature key](feature.md#feature-key) instead.
6 |
7 | ### Attributes
8 |
9 | An event entity is essentially a collection of **attributes** associated with an event name or feature key. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each event must have: `userId`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Event attributes are useful mainly when setting up event-based features which can be configured to match specific events based on these attributes. Another use case applies to automatic feedback surveys which can be set to trigger on a specific event based on a combination of attributes.
12 |
13 | Reflag manages a set of computed attributes when you send data to Reflag:
14 |
15 | * `First seen`**,** `Last seen` and `Event count` of the [users](user.md#attributes) and [companies](company.md#attributes),
16 | * `First used`**,** `Last used` and `Event count` of the [companies](company.md#attributes) relative to the [feature](feature.md#metrics) that matched the event.
17 |
18 | {% hint style="info" %}
19 | In Segment terminology, these events can be thought of as acting as a [Track](https://segment.com/docs/connections/spec/track/) call. Event attributes can be thought of as [Event traits](https://segment.com/docs/connections/spec/track/#sending-traits-in-a-track-call---destination-actions).
20 | {% endhint %}
21 |
22 | {% hint style="warning" %}
23 | Do not include PII data when sending in event attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
24 | {% endhint %}
25 |
26 | ### Next steps
27 |
28 | * Learn about [feedback](feedback.md) and setting up [automatic feedback surveys](../../product-handbook/launch-monitor/automated-feedback-surveys.md) within Reflag UI,
29 | * Learn how to [create an event-based feature](broken-reference) using user attributes within Reflag UI.
30 |
```
--------------------------------------------------------------------------------
/guides/self-opt-in.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How to create a beta feature self opt-in page in React with Reflag
3 | icon: browser
4 | ---
5 |
6 | # Beta feature opt-in
7 |
8 | Creating a page where users can opt into certain beta/experimental features is straightforward with Reflag and the Reflag React SDK.
9 |
10 | The basic concept is to set an attribute on the user/company which denotes that the user has self-opted into a specific feature, for example `optin-<featureKey> = true.` Updating an attribute is very simple from the SDK. Then use that attribute to control who has access to the feature by updating the feature access rules such that users/companies with the attribute `optin-<featureKey>=true` will have access to the feature.
11 |
12 | ## Step-by-step guide
13 |
14 | Here's a step-by-step guide:
15 |
16 | 1. Select a feature to let people self-opt into.
17 | 2. Add the rule: `optin-<featureKey> IS TRUE` to the rules section for all the environments. Replace `<featureKey>` with the actual feature key of the feature.
18 | 3. Use the following React component to let users self-opt opt-in to specific features:
19 |
20 | ```tsx
21 | import { useUpdateUser, useFlag, ReflagFeatures } from "@reflag/react-sdk";
22 | import { useState } from "react";
23 |
24 | function FeatureOptIn({
25 | featureKey,
26 | featureName,
27 | }: {
28 | featureKey: ReflagFeatures;
29 | featureName: string;
30 | }) {
31 | const updateUser = useUpdateUser();
32 | const [sendingUpdate, setSendingUpdate] = useState(false);
33 | const { isEnabled } = useFlag(featureKey);
34 |
35 | return (
36 | <div>
37 | <label htmlFor="huddlesOptIn">Opt-in to {featureName} feature</label>
38 | <input
39 | disabled={sendingUpdate}
40 | id="huddlesOptIn"
41 | type="checkbox"
42 | checked={isEnabled}
43 | onChange={() => {
44 | setSendingUpdate(true);
45 | updateUser({
46 | [`optin-${featureKey}`]: isEnabled ? "false" : "true",
47 | }).then(() => {
48 | setSendingUpdate(false);
49 | });
50 | }}
51 | />
52 | </div>
53 | );
54 | }
55 | ```
56 |
57 | ### How it works
58 |
59 | The React component above uses [remote attributes](https://reflag.com/changelog/introducing-remote-attributes) to ensure that any feature you've enabled stays enabled between sessions.
60 |
61 | ### Next steps
62 |
63 | * Learn how to manage who has access, and modify the [Targeting rules](../product-handbook/feature-rollouts/feature-targeting-rules.md) in the UI.
64 |
```
--------------------------------------------------------------------------------
/product-handbook/anonymous-users.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How to use Reflag with anonymous users
3 | ---
4 |
5 | # Anonymous users
6 |
7 | Reflag is designed for SaaS applications in which users are authenticated and belong to a company group. However, you can still use Reflag for certain use cases where users aren't authenticated.
8 |
9 | Example use cases:
10 |
11 | * Toggle features on/off for all anonymous users on marketing pages or docs.
12 | * For anonymous users that belong to companies, for example for a white-label solution for ordering food online: roll out features to anonymous users belonging to certain restaurants or roll it users belonging to a percentage of restaurants (companies).
13 |
14 | ### How to toggle features for anonymnous users
15 |
16 | First, create a new flag, use it on the respective feature and ship it.
17 |
18 | On the Access tab, you can now use "No-one" or "Everyone" to toggle the feature off and on. "Some" is not supported for anonymous users.
19 |
20 | For anonymous users you supply an empty user ID and empty company ID.
21 |
22 | {% tabs %}
23 | {% tab title="Node.js" %}
24 | ```typescript
25 | import { ReflagClient } from "@reflag/node-sdk";
26 |
27 | const client = new ReflagClient(...)
28 | // using an empty context for anonymous users
29 | const { isEnabled } = client.bindClient({}).getFlag("export-to-csv")
30 | ```
31 | {% endtab %}
32 |
33 | {% tab title="React" %}
34 | ```tsx
35 | import { ReflagProvider } from "@reflag/react-sdk";
36 |
37 | function App() {
38 | return (
39 | <ReflagProvider> // no user/company provided
40 | <Routes />
41 | </ReflagProvider>
42 | );
43 | }
44 |
45 | ```
46 | {% endtab %}
47 | {% endtabs %}
48 |
49 | ### How to toggle features for anonymous users where you know their company
50 |
51 | If the user is anonymous but you do know the company entity, you can simply supply the given company ID and an empty user ID. This lets you control features for anonymous users beloning to the given company.
52 |
53 | {% tabs %}
54 | {% tab title="Node.js" %}
55 | ```typescript
56 | import { ReflagClient } from "@reflag/node-sdk";
57 |
58 | const client = new ReflagClient(...)
59 |
60 | // supply only the company ID if the users is anonymous but belongs to a company
61 | const { isEnabled } = client.bindClient({company: {id: "petes-burgers"}).getFlag("export-to-csv")
62 | ```
63 | {% endtab %}
64 |
65 | {% tab title="React" %}
66 | ```tsx
67 | import { ReflagProvider } from "@reflag/react-sdk";
68 |
69 | function App() {
70 | return (
71 | <ReflagProvider company={{id: "petes-burgers"}}> // company provided
72 | <Routes />
73 | </ReflagProvider>
74 | );
75 | }
76 |
77 | ```
78 | {% endtab %}
79 | {% endtabs %}
80 |
81 |
```
--------------------------------------------------------------------------------
/.gitbook/includes/integrations.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | title: Integrations
3 | ---
4 |
5 | <table data-view="cards" data-full-width="true"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>Get notified about feature changes and feedback</td><td></td><td><a href="../assets/slack.svg">slack.svg</a></td><td><a href="../../integrations/slack.md">slack.md</a></td></tr><tr><td>Create feature flags from Linear</td><td></td><td><a href="../assets/linear.svg">linear.svg</a></td><td><a href="../../integrations/linear.md">linear.md</a></td></tr><tr><td>Clean-up code references with AI</td><td></td><td><a href="../assets/github-logo.svg">github-logo.svg</a></td><td><a href="../../integrations/github.md">github.md</a></td></tr><tr><td>Work with Reflag flags using the Vercel toolbar</td><td></td><td><a href="../assets/vercel-logo.svg">vercel-logo.svg</a></td><td><a href="https://flags-sdk.dev/providers/bucket">https://flags-sdk.dev/providers/bucket</a></td></tr><tr><td>Catch regressions on feature releases</td><td></td><td><a href="../assets/datadog.svg">datadog.svg</a></td><td><a href="../../integrations/datadog.md">datadog.md</a></td></tr><tr><td>Query analytics based on feature access filters</td><td></td><td><a href="../assets/posthog.svg">posthog.svg</a></td><td><a href="../../integrations/posthog.md">posthog.md</a></td></tr><tr><td>Track feature adoption metrics</td><td></td><td><a href="../assets/segment.svg">segment.svg</a></td><td><a href="../../integrations/segment.md">segment.md</a></td></tr><tr><td>Query analytics based on feature access filters</td><td></td><td><a href="../assets/amplitude.svg">amplitude.svg</a></td><td><a href="../../integrations/amplitude.md">amplitude.md</a></td></tr><tr><td>Query analytics based on feature access filters</td><td></td><td><a href="../assets/mixpanel.svg">mixpanel.svg</a></td><td><a href="../../integrations/mixpanel.md">mixpanel.md</a></td></tr><tr><td>Export feature data for CS, Marketing, and Sales tools</td><td></td><td><a href="../assets/aws-s3.svg">aws-s3.svg</a></td><td><a href="../../integrations/aws-s3.md">aws-s3.md</a></td></tr><tr><td>Share flag access with your docs to personalize them. </td><td></td><td><a href="../assets/gitbook-logo.svg">gitbook-logo.svg</a></td><td><a href="https://gitbook.com/docs/publishing-documentation/adaptive-content/enabling-adaptive-content/feature-flags#bucket">https://gitbook.com/docs/publishing-documentation/adaptive-content/enabling-adaptive-content/feature-flags#bucket</a></td></tr></tbody></table>
6 |
```
--------------------------------------------------------------------------------
/integrations/aws-s3.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Export feature data for CS, Marketing, and Sales tools, via Amazon AWS S3
3 | ---
4 |
5 | # AWS S3
6 |
7 | To configure an automatic data export to an Amazon S3 bucket, follow the steps below.
8 |
9 | ## Implementation steps
10 |
11 | 1. Log into the AWS Console. Navigate to `Identity and Access Management (IAM)` and select the `Users` option.\
12 |
13 |
14 | <figure><img src="../.gitbook/assets/630b5e9-image.png" alt=""><figcaption></figcaption></figure>
15 | 2. For security reasons, we recommend creating a new restricted user to access the designated S3 bucket. Use the `Create user` button to create a new user.
16 | 3. Select the desired user in the `Users` window, then click on the `Security credentials tab` and scroll down to the `Access Keys` section. \
17 | \
18 | There, click `Create Access Key` to obtain a new **Access Key** and **Secret Access Key.**\
19 |
20 |
21 | <figure><img src="../.gitbook/assets/1a0b50d-image.png" alt=""><figcaption></figcaption></figure>
22 | 4. Copy the user's ARN (AWS unique resource number). The ARN will be required when setting up the permissions on the S3 bucket.
23 | 5. Navigate to [https://s3.console.aws.amazon.com/s3/buckets/](https://s3.console.aws.amazon.com/s3/buckets/) to open the S3 configuration section.
24 | 6. Create or select an existing S3 bucket. \
25 | \
26 | In the bucket details pane, create a new folder (optional), and use the `Copy URL` functionality to get the public URL. \
27 | \
28 | This URL will be required when configuring the `Scheduled Data Export` in Reflag.
29 | 7. Switch to the `Permissions` tab of the S3 bucket details window. 
30 | 8. Scroll down to the `Bucket policy` section. Normally, if no other policies have been set up, it will be empty. 
31 | 9. Click on `Edit` and paste the policy below into the editor. \
32 | \
33 | If there are already other statements in the S3 bucket's policy, copy the statement object and paste it into the list. \
34 | \
35 | Replace `<user_arn>` and `<bucket_arn>` with the real values from your AWS account.
36 |
37 | ```json
38 | {
39 | "Version": "2012-10-17",
40 | "Statement": [
41 | {
42 | "Sid": "AllowReflagDotCom",
43 | "Effect": "Allow",
44 | "Principal": {
45 | "AWS": "<user_arn>"
46 | },
47 | "Action": [
48 | "s3:PutObject",
49 | "s3:PutObjectAcl",
50 | "s3:ListBucket",
51 | "s3:AbortMultipartUpload",
52 | "s3:PutObjectTagging"
53 | ],
54 | "Resource": [
55 | "<bucket_arn>",
56 | "<bucket_arn>/*"
57 | ]
58 | }
59 | ]
60 | }
61 | ```
62 |
63 | Following the steps above should give you the **URL**, **Access Key**, and **Secret Access Key** settings required to configure an automatic data export.
64 |
```
--------------------------------------------------------------------------------
/integrations/linear.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: Create features and manage access in Linear
3 | ---
4 |
5 | # Linear
6 |
7 | ## Connect to Linear
8 |
9 | For most integrations, you first need connect Reflag with your Linear account. To do so:
10 |
11 | 1. Navigate to **Settings** > **Organization**
12 | 2. Click "**Connect to Linear**"
13 | 3. For the [Agent](linear.md#agent) integration, **select the app** you want to manage in the dropdown.
14 |
15 |
16 |
17 | ## Integrations
18 |
19 | <table><thead><tr><th width="218.89453125">Name</th><th>Use case</th></tr></thead><tbody><tr><td><strong>Agent @-mention</strong></td><td>Create features and manage feature access from Linear</td></tr><tr><td><strong>Broadcast</strong></td><td>Share feature access changes to Linear issues or projects</td></tr><tr><td><strong>Project template</strong></td><td>Add default issue to create feature flag in new Linear projects</td></tr></tbody></table>
20 |
21 | ***
22 |
23 | ### Agent @-mention
24 |
25 | The Agent integration enables you to `@reflag` within Linear. 
26 |
27 | {% embed url="https://139729605.fs1.hubspotusercontent-eu1.net/hubfs/139729605/Videos/bucketco-website/linear-agent-create-flag_h264.mp4" %}
28 |
29 | #### Creating features
30 |
31 | Example: `@reflag create feature flag for this issue` 
32 |
33 | #### Managing feature access and stage
34 |
35 | Example: `@reflag release to everyone and bump stage to GA` 
36 |
37 | If there's a Customer Request, try: `@reflag release to the customers that requsted it`
38 |
39 | #### Link issue to feature
40 |
41 | Example: `@reflag link to <feature name/key>`
42 |
43 |
44 |
45 | ***
46 |
47 | ### Broadcast
48 |
49 | The broadcast integration posts feature access change to a Linear issue or project.
50 |
51 | <figure><img src="../.gitbook/assets/image.png" alt=""><figcaption></figcaption></figure>
52 |
53 | Here's how to get started:\
54 |
55 |
56 | 1. Make sure you've [connected](linear.md#first-connect-to-linear) to Linear.
57 | 2. In the feature sidebar, select a Linear issue or project.
58 | 3. Whenever you change feature access or stage, you can choose to also send the changes to the chosen Linear issue or project.
59 |
60 | When you link a feature with a Linear issue or project, you'll see a link to the feature on the Linear issue or in the project resources.
61 |
62 |
63 |
64 | ***
65 |
66 | ### Template
67 |
68 | When you start working on a new project in Linear, we recommend adding a "Create feature flag" issue. 
69 |
70 | <figure><img src="../.gitbook/assets/image (1).png" alt="A Linear project template with an issue included by default to make it easy to get started with features in Reflag"><figcaption><p>A Linear project template with an issue included by default to make it easy to get started with features in Reflag</p></figcaption></figure>
71 |
72 | This way, when you start a new project, part of the initial work will be setting up a feature in Reflag. 
73 |
74 | By using [Linear project templates](https://linear.app/docs/project-templates#create-templates), you can automate this so that all new projects come with the option to create a Reflag issue.
75 |
76 | Pro tip: You can link directly to Reflag's "New feature" modal with the [flag.new](https://flag.new) shortcut.
77 |
78 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/company.md:
--------------------------------------------------------------------------------
```markdown
1 | # Company
2 |
3 | ### Definition
4 |
5 | A **company** entity in Reflag is used to group [users](user.md), [events](event.md) and [feedback](feedback.md). All data sent to Reflag from your side will be associated with a company in one way or another. For instance, when updating the details of an user, the company ID can be supplied to inform Reflag that the user "_has been seen_" acting as part of said company. In other cases, if the company is not explicitly identified, Reflag will use the last known company (default) that the user was part of.
6 |
7 | ### Attributes
8 |
9 | A company entity, aside from being a group for users acting in its stead, is also a collection of **attributes**. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each company must have: `ID`, and two special attributes Reflag uses in its UI for convenience: `name` and `avatar`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Reflag manages a set of computed attributes when you send data to Reflag:
12 |
13 | * `First seen` and `Last seen` denote the first and last time the company-related interactions have been sent to Reflag,
14 | * `Event count` is updated any time there is a new [event](event.md) received referencing the company.
15 |
16 | Some use cases for company attributes could be: "_plan_" or "_tier_" to identify the subscription status; "_monthly spend_"; "_geographic location_", etc. Any company attribute can be used in [company segments](segment.md), attribute-based [features](feature.md) as well as any [targeting rule](targeting-rules.md).
17 |
18 | {% hint style="info" %}
19 | In Segment terminology, companies can be thought of as acting as a [Group](https://segment.com/docs/connections/spec/group/) call. Company attributes can be thought of as [Group traits](https://segment.com/docs/connections/spec/group/).
20 | {% endhint %}
21 |
22 | {% hint style="warning" %}
23 | Do not include PII data when sending in company attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
24 | {% endhint %}
25 |
26 | ### Associating with users
27 |
28 | [Events](event.md) sent to Reflag from your application, are usually identified only by the [user](user.md) that triggered said event. To associate these events with a [company](company.md), make sure to associate the user with one. You can associate the user with multiple companies — each time the user is seen acting as part of another company, Reflag remembers, and the company becomes the new "_default_" for the user. Every subsequent event that lacks explicit company information will be associated with the default.
29 |
30 | {% hint style="info" %}
31 | [Reflag SDKs](../../supported-languages/overview.md) automatically maintain the associations between users and companies, as long as you supply their respective details on initialization. 
32 | {% endhint %}
33 |
34 | {% hint style="warning" %}
35 | If a user's events aren't associated with a company, they will not be included in Reflag (which is primarily based on company-level activity).
36 | {% endhint %}
37 |
38 | ### Next steps
39 |
40 | * Learn about [users](user.md), [events](event.md) and [segments](segment.md),
41 | * Learn how to [create company segments](../creating-segments.md) within Reflag UI.
42 |
```
--------------------------------------------------------------------------------
/product-handbook/service-resiliency.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: How we keep your product working even if the Reflag service is disrupted.
3 | ---
4 |
5 | # Service Resiliency
6 |
7 | To keep your product working even if the Reflag service is disrupted, we provide a number of safe guards and features that build resiliency.
8 |
9 | ### Local evaluation
10 |
11 | To improve latency and provide downtime protection, local evaluation is supported in our [node-sdk](../sdk/@reflag/node-sdk/) and [openfeature-node-sdk](../supported-languages/openfeature.md).
12 |
13 | Ordinarily, our SDKs send your user/company attributes to our servers and return a list of flags that should be enabled. However, to avoid potential downtime, you can evaluate flags locally on your servers instead of sending a request to our servers.
14 |
15 | With local evaluation, our SDKs will download the flag definitions from our servers and run checks against the rules using the given user and company properties locally instead of contacting our servers for every evaluation. The SDK caches the downloaded list in memory, so will keep working during service disruption so long as the service that is using the SDK doesn't get rebooted.
16 |
17 | ### Edge-runtime (like Cloudflare Workers) support
18 |
19 | Equally as effective as local evaluation is our [support for edge-runtimes](service-resiliency.md#edge-runtime-like-cloudflare-workers-support) like Cloudflare Workers, also in the Node SDK.
20 |
21 | Reflag maintains a cached set of flag definitions in the memory to decide which features to turn on for which users/companies.
22 |
23 | The EdgeClient uses a strategy to keep these feature definitions fresh: The first request to a new worker instance fetches definitions from Reflag's servers, while subsequent requests use the cache. During an invocation, when the cache has expired, the request will be served using the stale cache while it’s being updated in the background, so response times are not affected. However, during downtime, this cache would continue to be served.
24 |
25 | ### Bootstrapped flags
26 |
27 | With [getFlagsForBootstrap()](https://docs.reflag.com/supported-languages/node-sdk#bootstrapping-client-side-applications) in the Node SDK and [ReflagBootstrappedProvider](https://docs.reflag.com/supported-languages/react-sdk#server-side-rendering-and-bootstrapping) in the React SDK, you can evaluate flags on the server and pass them to your client-side applications.
28 |
29 | Bootstrapping is recommended as it means that the server has local evaluation and will pass the evaluated flags to the frontend on load, further protecting you from service disruption.
30 |
31 | ### Offline flags
32 |
33 | We also provide [Offline Mode](https://docs.reflag.com/supported-languages/node-sdk#configuring) in all our SDKs, which, when enabled, means we use [flag overrides](https://docs.reflag.com/supported-languages/node-sdk#flag-overrides). This is generally useful during testing and local development; however, it can also be supplied to the SDKs so that they are used as defaults if our servers are down.
34 |
35 | ### Client SDK caching
36 |
37 | Finally, all client SDKs (web) cache the last flags and will keep using those until our servers respond with fresh data. This won’t help if the page was loaded when our servers were down, but bootstrapping from your server would mitigate this.
38 |
```
--------------------------------------------------------------------------------
/introduction/concepts/company.md:
--------------------------------------------------------------------------------
```markdown
1 | # Company
2 |
3 | ### Definition
4 |
5 | A **company** entity in Reflag is used to group [users](user.md), [events](event.md) and [feedback](feedback.md). All data sent to Reflag from your side will be associated with a company in one way or another. For instance, when updating the details of an user, the company ID can be supplied to inform Reflag that the user "_has been seen_" acting as part of said company. In other cases, if the company is not explicitly identified, Reflag will use the last known company (default) that the user was part of.
6 |
7 | ### Attributes
8 |
9 | A company entity, aside from being a group for users acting in its stead, is also a collection of **attributes**. Each attribute is a **key** — **value** pair supplied by your application. There is one mandatory attribute each company must have: `ID`, and two special attributes Reflag uses in its UI for convenience: `name` and `avatar`. It is up to you to provide whichever attributes you deem necessary.
10 |
11 | Reflag manages a set of computed attributes when you send data to Reflag:
12 |
13 | * `First seen` and `Last seen` denote the first and last time the company-related interactions have been sent to Reflag,
14 | * `Event count` is updated any time there is a new [event](event.md) received referencing the company.
15 |
16 | Some use cases for company attributes could be: "_plan_" or "_tier_" to identify the subscription status; "_monthly spend_"; "_geographic location_", etc. Any company attribute can be used in [company segments](segment.md), attribute-based [features](feature.md) as well as any [targeting rule](targeting-rules.md).
17 |
18 | {% hint style="info" %}
19 | In Segment terminology, companies can be thought of as acting as a [Group](https://segment.com/docs/connections/spec/group/) call. Company attributes can be thought of as [Group traits](https://segment.com/docs/connections/spec/group/).
20 | {% endhint %}
21 |
22 | {% hint style="warning" %}
23 | Do not include PII data when sending in company attributes. It is recommended that any sensitive data should be hashed or otherwise not included.
24 | {% endhint %}
25 |
26 | ### Associating with users
27 |
28 | [Events](event.md) sent to Reflag from your application, are usually identified only by the [user](user.md) that triggered said event. To associate these events with a [company](company.md), make sure to associate the user with one. You can associate the user with multiple companies — each time the user is seen acting as part of another company, Reflag remembers, and the company becomes the new "_default_" for the user. Every subsequent event that lacks explicit company information will be associated with the default.
29 |
30 | {% hint style="info" %}
31 | [Reflag SDKs](../../supported-languages/overview.md) automatically maintain the associations between users and companies, as long as you supply their respective details on initialization. 
32 | {% endhint %}
33 |
34 | {% hint style="warning" %}
35 | If a user's events aren't associated with a company, they will not be included in Reflag (which is primarily based on company-level activity).
36 | {% endhint %}
37 |
38 | ### Next steps
39 |
40 | * Learn about [users](user.md), [events](event.md) and [segments](segment.md),
41 | * Learn how to [create company segments](../../product-handbook/feature-targeting-rules/creating-segments.md) within Reflag UI.
42 |
```
--------------------------------------------------------------------------------
/api/api-access.md:
--------------------------------------------------------------------------------
```markdown
1 | ---
2 | description: >-
3 | Understand when to use the Reflag Public API and when to use the Reflag REST
4 | API
5 | ---
6 |
7 | # API Access
8 |
9 | Reflag offers two distinct APIs:
10 |
11 | 1. [**Public API**](public-api/public-api-reference.md): This API is required for interaction with customer applications through our SDK or directly via the Public API endpoints. It utilizes two types of keys:
12 |
13 | * **Publishable Key**: Used in client-side code to securely connect to Reflag services.
14 | * **Secret Key**: Employed in server-side environments to safeguard sensitive interactions and data.
15 |
16 | Each environment on Reflag has a publishable key and a secret key.
17 | 2. [**REST API:**](reflag-rest-api/reflag-api-reference.md) This API can be used by customers to directly access and manipulate their account in Reflag (such as listing apps, flags, and amending targeting rules). API Keys govern access to the REST API. API Keys are bound to your Reflag app.
18 |
19 | ## Public API and SDK Access
20 |
21 | To use the Reflag SDKs and/or Reflag Public API, you will need an environment-specific SDK key. These keys are unique to each environment on Reflag and ensure secure interaction with data in that environment only. While the data (flag targeting, companies, users, events, etc.) are environment-specific, the exposed flag details and remote config values are shared across all environments.
22 |
23 | When developing client-facing code, such as web, mobile, or any publicly accessible applications, utilize the **"Publishable key"**. This key is safe to share, as it has limited permissions for accessing and transmitting information.
24 |
25 | Utilize the **"Secret key"** to access additional data like targeting rule definitions and secret flags. This key is intended for use in server-side environments only and must remain confidential.
26 |
27 | Refer to the [Reflag SDKs ](broken-reference)documentation for detailed information on useful keys for each flag.
28 |
29 | {% hint style="warning" %}
30 | SDK keys are auto-generated by Reflag for each app environment and cannot be changed.
31 | {% endhint %}
32 |
33 | <figure><img src="../.gitbook/assets/image (31).png" alt=""><figcaption><p>The SDK and API keys</p></figcaption></figure>
34 |
35 | ## REST API Access
36 |
37 | The REST API allows for direct manipulation of your Reflag account, simplifying processes by bypassing the need for the Reflag web app interface. This enables programmatic control over environment settings, flag configurations, and more, providing flexibility and automation for developers.
38 |
39 | One primary use case is the [Reflag CLI,](../sdk/documents/cli/) which can be configured in CI/CD pipelines when given the API key. This setup enables seamless flag management during automated deployment processes, enhancing workflow efficiency and consistency across different stages of deployment.
40 |
41 | To start, create a new API key and select its scopes. After setting the necessary scopes, securely store the API key for use in your CI/CD pipelines or other automated processes.
42 |
43 | <figure><img src="../.gitbook/assets/image (32).png" alt="" width="563"><figcaption><p>Create a new API key</p></figcaption></figure>
44 |
45 | After clicking _"Create,"_ you'll receive the API key. Remember to save it, as you won't be able to retrieve it later.
46 |
47 | {% hint style="warning" %}
48 | Select only the necessary scopes for your API keys. Limit permissions and delete unused keys.
49 | {% endhint %}
50 |
51 |
```
--------------------------------------------------------------------------------
/.gitbook/assets/vercel-logo.svg:
--------------------------------------------------------------------------------
```
1 | <svg width="512" height="289" viewBox="0 0 512 289" fill="none" xmlns="http://www.w3.org/2000/svg">
2 | <style>@media (prefers-color-scheme: dark) { path { fill: white; }}</style>
3 | <path fill-rule="evenodd" clip-rule="evenodd" d="M169.53 176L132.765 112L96 176H169.53ZM206.612 173.087L237.337 114.909H224.047L202.853 157.16L181.658 114.909H168.368L199.093 173.087H206.612ZM416 114.909V173.087H404.998V114.909H416ZM354.758 151.372C354.758 146.838 355.703 142.851 357.594 139.409C359.485 135.968 362.121 133.318 365.501 131.461C368.882 129.604 372.836 128.675 377.364 128.675C381.375 128.675 384.985 129.549 388.194 131.297C391.403 133.045 393.953 135.64 395.843 139.081C397.734 142.523 398.709 146.729 398.766 151.7V154.24H366.362C366.59 157.846 367.65 160.686 369.541 162.762C371.49 164.783 374.098 165.794 377.364 165.794C379.426 165.794 381.318 165.248 383.036 164.155C384.755 163.062 386.045 161.588 386.904 159.73L398.165 160.55C396.789 164.647 394.211 167.924 390.429 170.382C386.646 172.841 382.292 174.07 377.364 174.07C372.836 174.07 368.882 173.141 365.501 171.284C362.121 169.427 359.485 166.777 357.594 163.336C355.703 159.894 354.758 155.906 354.758 151.372ZM387.42 147.275C387.019 143.725 385.902 141.13 384.068 139.491C382.234 137.798 380 136.951 377.364 136.951C374.326 136.951 371.863 137.852 369.972 139.655C368.08 141.458 366.906 143.998 366.447 147.275H387.42ZM336.193 139.491C338.027 140.966 339.172 143.014 339.632 145.636L350.976 145.063C350.575 141.731 349.402 138.836 347.453 136.377C345.504 133.919 342.984 132.035 339.888 130.723C336.852 129.358 333.5 128.675 329.832 128.675C325.305 128.675 321.352 129.604 317.97 131.461C314.589 133.318 311.953 135.968 310.062 139.409C308.171 142.851 307.226 146.838 307.226 151.372C307.226 155.906 308.171 159.894 310.062 163.336C311.953 166.777 314.589 169.427 317.97 171.284C321.352 173.141 325.305 174.07 329.832 174.07C333.613 174.07 337.052 173.387 340.146 172.021C343.242 170.601 345.762 168.607 347.711 166.04C349.66 163.472 350.833 160.468 351.234 157.026L339.803 156.535C339.402 159.43 338.284 161.67 336.451 163.254C334.617 164.783 332.41 165.548 329.832 165.548C326.28 165.548 323.529 164.319 321.58 161.861C319.632 159.403 318.659 155.906 318.659 151.372C318.659 146.838 319.632 143.342 321.58 140.884C323.529 138.426 326.28 137.197 329.832 137.197C332.297 137.197 334.416 137.961 336.193 139.491ZM280.381 129.656H290.62L290.915 138.015C291.642 135.649 292.652 133.812 293.947 132.503C295.823 130.605 298.441 129.656 301.796 129.656H305.977V138.603H301.711C299.322 138.603 297.36 138.928 295.823 139.579C294.345 140.229 293.207 141.259 292.411 142.669C291.672 144.079 291.302 145.868 291.302 148.037V173.087H280.381V129.656ZM233.155 139.409C231.264 142.851 230.319 146.838 230.319 151.372C230.319 155.906 231.264 159.894 233.155 163.336C235.046 166.777 237.682 169.427 241.063 171.284C244.444 173.141 248.398 174.07 252.925 174.07C257.852 174.07 262.208 172.841 265.989 170.382C269.773 167.924 272.351 164.647 273.726 160.55L262.466 159.73C261.607 161.588 260.317 163.062 258.598 164.155C256.879 165.248 254.988 165.794 252.925 165.794C249.659 165.794 247.051 164.783 245.103 162.762C243.212 160.686 242.152 157.846 241.923 154.24H274.328V151.7C274.27 146.729 273.296 142.523 271.405 139.081C269.515 135.64 266.965 133.045 263.756 131.297C260.547 129.549 256.937 128.675 252.925 128.675C248.398 128.675 244.444 129.604 241.063 131.461C237.682 133.318 235.046 135.968 233.155 139.409ZM259.63 139.491C261.462 141.13 262.581 143.725 262.982 147.275H242.008C242.467 143.998 243.642 141.458 245.533 139.655C247.424 137.852 249.888 136.951 252.925 136.951C255.56 136.951 257.796 137.798 259.63 139.491Z" fill="#09090B"/>
4 | </svg>
5 |
```
--------------------------------------------------------------------------------
/.gitbook/assets/next-js.svg:
--------------------------------------------------------------------------------
```
1 | <svg width="512" height="289" viewBox="0 0 512 289" fill="none" xmlns="http://www.w3.org/2000/svg">
2 | <style>
3 | @media (prefers-color-scheme: dark) {
4 | path { fill: white; }
5 | }
6 | </style>
7 | <path d="M308.067 112.026H363.109V122.16H341.274V175.471H330.356V122.16H308.067V112.026Z" fill="black"/>
8 | <path d="M217.544 112.026V122.16H173.425V138.462H208.906V148.595H173.425V165.338H217.544V175.471H162.507V122.16H162.503V112.026H217.544Z" fill="black"/>
9 | <path d="M245.028 112.053H230.741L281.915 175.498H296.244L270.654 143.797L296.203 112.101L281.915 112.123L263.5 134.936L245.028 112.053Z" fill="black"/>
10 | <path d="M259.689 157.372L252.534 148.498L230.7 175.546H245.028L259.689 157.372Z" fill="black"/>
11 | <path fill-rule="evenodd" clip-rule="evenodd" d="M162.89 175.471L111.647 112H98V175.445H108.917V125.561L149.175 175.471H162.89Z" fill="black"/>
12 | <path d="M365.563 175.084C364.763 175.084 364.083 174.807 363.514 174.255C362.944 173.702 362.663 173.033 362.67 172.241C362.663 171.47 362.944 170.808 363.514 170.256C364.083 169.703 364.763 169.427 365.563 169.427C366.332 169.427 367.005 169.703 367.574 170.256C368.152 170.808 368.44 171.47 368.448 172.241C368.44 172.764 368.307 173.244 368.04 173.673C367.767 174.109 367.42 174.451 366.983 174.698C366.554 174.953 366.08 175.084 365.563 175.084Z" fill="black"/>
13 | <path d="M384.197 148.356H389.034V166.948C389.027 168.656 388.657 170.118 387.932 171.347C387.2 172.575 386.186 173.513 384.885 174.175C383.59 174.829 382.074 175.164 380.35 175.164C378.774 175.164 377.362 174.88 376.104 174.328C374.847 173.775 373.848 172.946 373.116 171.855C372.375 170.765 372.013 169.405 372.013 167.777H376.859C376.866 168.489 377.029 169.107 377.339 169.623C377.65 170.14 378.079 170.532 378.626 170.808C379.181 171.085 379.817 171.223 380.535 171.223C381.312 171.223 381.977 171.063 382.517 170.736C383.057 170.416 383.472 169.936 383.76 169.296C384.041 168.664 384.189 167.878 384.197 166.948V148.356Z" fill="black"/>
14 | <path d="M408.94 155.627C408.822 154.5 408.304 153.62 407.402 152.995C406.491 152.362 405.315 152.05 403.873 152.05C402.86 152.05 401.987 152.203 401.262 152.501C400.537 152.806 399.975 153.213 399.59 153.729C399.206 154.246 399.013 154.835 398.998 155.496C398.998 156.049 399.131 156.529 399.39 156.929C399.649 157.336 399.996 157.677 400.448 157.954C400.891 158.237 401.387 158.47 401.928 158.659C402.475 158.848 403.022 159.008 403.569 159.139L406.092 159.757C407.106 159.99 408.09 160.302 409.029 160.702C409.968 161.095 410.819 161.596 411.566 162.2C412.313 162.803 412.905 163.53 413.341 164.381C413.778 165.232 414 166.228 414 167.377C414 168.925 413.6 170.285 412.794 171.463C411.988 172.633 410.826 173.55 409.302 174.211C407.786 174.866 405.952 175.2 403.792 175.2C401.706 175.2 399.886 174.88 398.355 174.24C396.816 173.608 395.617 172.677 394.752 171.456C393.887 170.234 393.421 168.744 393.354 166.991H398.148C398.214 167.907 398.51 168.671 399.013 169.289C399.523 169.9 400.189 170.35 401.003 170.656C401.824 170.954 402.741 171.107 403.755 171.107C404.813 171.107 405.745 170.947 406.551 170.634C407.349 170.321 407.978 169.885 408.43 169.318C408.889 168.758 409.118 168.096 409.125 167.34C409.118 166.65 408.91 166.075 408.511 165.624C408.104 165.174 407.542 164.796 406.824 164.49C406.1 164.185 405.256 163.908 404.294 163.669L401.232 162.898C399.02 162.338 397.267 161.487 395.987 160.346C394.701 159.204 394.064 157.692 394.064 155.794C394.064 154.238 394.493 152.872 395.359 151.701C396.216 150.53 397.393 149.621 398.88 148.974C400.374 148.32 402.061 148 403.939 148C405.848 148 407.519 148.32 408.962 148.974C410.404 149.621 411.537 150.523 412.357 151.672C413.179 152.821 413.608 154.137 413.63 155.627H408.94Z" fill="black"/>
15 | </svg>
16 |
```
--------------------------------------------------------------------------------
/product-handbook/concepts/filter.md:
--------------------------------------------------------------------------------
```markdown
1 | # Filter
2 |
3 | ### Definition
4 |
5 | A filter, in Reflag, is a mechanism that is used to check if entities such as [user](user.md), [company](company.md), [event](event.md), etc. match a set of predicates. Filters can also be aggregated into logical expressions, thus, facilitating advanced use cases.
6 |
7 | Reflag support the following filter types:
8 |
9 | * [Company attribute](company.md#attributes) filter, that can be used to check company attributes,
10 | * Company [feature metrics](feature.md#metrics) filter, which allows checking for feature metrics applied to a given company,
11 | * [User attribute](user.md#attributes) filter, used to check user attributes,
12 | * [Event attribute](event.md#attributes) filter, used to check event attributes,
13 | * Company [segment](segment.md) filter, can be used to check a company's membership in a segment,
14 | * [Flag access](feature.md#access) filter, can be used to check whether a company has access to a flag,
15 | * [Gradual rollout](../feature-rollouts/#gradually-roll-out-your-feature) filter, is used in advanced scenarios to evaluate whether a company matches target rollout bracket,
16 | * [Other context](targeting-rules.md#evaluation-context) filter, used when rules can access additional context, in addition to user and company attributes.
17 |
18 | ### Company attribute filter
19 |
20 | This filter can be used to check company attributes against a set predicates. The attributes include the `First seen` and `Last seen` which are maintained by Reflag. You can use any attribute name that your application sent to Reflag.
21 |
22 | ### Company feature metrics
23 |
24 | This filter allows checking company's feature-specific metrics. These metrics include things like `Event count`, `First used`, `Last used`, end etc.
25 |
26 | ### User attribute filter
27 |
28 | This filter can be used to check user attributes against a set predicates. You can use any attribute name that your application sent to Reflag when updating user.
29 |
30 | ### Event attribute filter
31 |
32 | This filter can be used to check event attributes against a set predicates. You can use any attribute name that your application sent to Reflag when sending track events.
33 |
34 | ### Company segment filter
35 |
36 | This filter can be used to check if a given company is (or not) included in a given segment. The filter essentially evaluates the segment's filter against the company.
37 |
38 | ### Flag access filter
39 |
40 | This filter can be used to check if a given company has (or not) access to a given flag. The filter evaluates the flag's targeting rules against the provided company, and assumes skips evaluation of any non-company attribute related filters.
41 |
42 | ### Gradual rollout filter
43 |
44 | This filter is used by feature access targeting when enabling gradual rollout. It will bracket the pool of companies based on a predictable hashing algorithm and check if the company falls within the rollout percentage.
45 |
46 | ### Other context filter
47 |
48 | This filter can be used to check `other` context attributes against a set predicates. You can use any attribute name that your application sends to Reflag when evaluating feature access.
49 |
50 | {% hint style="warning" %}
51 | * Company attribute filters using `First seen` and `Last seen` attributes cannot be used in targeting rules,
52 | * Company feature metrics filters are not supported in targeting rules,
53 | * Event attribute filter is only used in event-based feature and automatic feedback surveys,
54 | * Gradual rollout filter is only used in feature access targeting rules,
55 | * Other context filter is only used in feature access targeting rules,
56 |
57 |  Any filters that build up on on other filters inherit the restrictions of the filters they are based on.
58 | {% endhint %}
59 |
60 | ### Next steps
61 |
62 | * Learn in depth how to use filters in [setup feature access rules](../feature-rollouts/feature-targeting-rules.md).
63 |
```
