Widget security model
What the API key does, what it doesn't, and how the widget stays inside the trust boundary.
- Last reviewed
Widget security model
The widget is designed for browser use. Some pieces are intentionally public and some are not.
What the API key does
The API key identifies which app the request belongs to. It scopes all widget traffic — flows, responses, identity calls — to your app.
The API key is not a secret. It's meant to be visible in your frontend code, just like a Google Analytics tracking ID.
What someone can do with your API key
- See published flows that are configured to display on your app.
- Submit responses to those flows.
What they can't do
- Access other apps or other organizations.
- Read responses, user data, or analytics.
- Modify flows, targeting rules, or settings.
- Have identity values marked as verified without a valid token containing matching claims when identity verification is enabled.
The API key is a public identifier, not an access token. All read and write access to your data goes through the getuserfeedback.com dashboard, which has its own authentication.
What controls trust
Trust comes from the app's configuration and the signals you send:
- Identity verification — when enabled, requests without a valid signed token from your app are rejected. Identity values matching configured claims in that token are marked as verified.
- User identity via
identify()— ties responses to known users. - Consent — controls which non-essential data scopes are active.
- App scoping — all requests are scoped to one app key. Cross-app access is not possible.
Consistent across SDKs
The JavaScript SDK, React SDK, and Google Tag Manager all share the same security model:
- Identify the user if needed
- Configure identity verification if needed
- Open the flow
- Reset state on logout
Switching between SDKs doesn't require a different security setup.