In this section
Resources / Installation / Configuration
Cookies, CORS and credentials
Which cookies Hubbo sets, why the embed uses crossorigin="use-credentials", and how CORS is configured.
Hubbo runs on a different host (api.hubbo.io) than your website. To keep content safe and page-view counting honest, it uses credentialed cross-origin requests. This article explains each piece.
Cookies set by Hubbo
| Cookie | Set by | Purpose |
|---|---|---|
| hubbo_api_key | api.hubbo.io/embed | Stores your account key for the embed. httpOnly, Secure, SameSite=None. |
| hubbo_pv_* | api.hubbo.io | Marks that this browser session has already been counted as a page view for the account. httpOnly, one cookie per account. |
| hubbo_chat_* | api.hubbo.io (GraphQL createChat) | Short-lived guest chat token for continuing a conversation on a public notification page. httpOnly, Secure, SameSite=None, about 24 hours. |
These cookies are set on the Hubbo API host and cannot be read or modified by JavaScript running on your page. This is intentional: the page-view counter and guest chat tokens must not be forgeable by scripts on the host site.
In addition to the cookies, the widget keeps a small hubbo entry in the visitor’s localStorage on your own origin. It remembers which notifications were already shown and the timing and throttling decisions for NPS and surveys, so people are not asked repeatedly. If storage is blocked or unavailable, the widget carries on without it. Guest chats on the public notification page are ephemeral in the browser (a refresh starts a new conversation); your team still sees every thread in Messages.
Page views = browser sessions
The hubbo_pv_* cookie is a session cookie. While the browser stays open, further notifications, NPS, survey, roadmap or status loads do not add page views. When the visitor closes the browser and returns, a new session starts and counts again.
Why crossorigin="use-credentials"
The crossorigin="use-credentials" attribute tells the browser to send and accept cookies when loading the script from api.hubbo.io. Without it the hubbo_api_key cookie may not be stored and the widget cannot identify your account. The same applies to the credentialed GraphQL requests the widget makes after it boots.
CORS
The API answers CORS preflight requests. When the request Origin is allow-listed, the response reflects that origin and sets Access-Control-Allow-Credentials: true (credentials are never advertised without an allow-listed origin). Allowed origins are:
- The website origin saved in your account (for example
https://example.com). Changing it in Account settings takes effect within about 30 seconds — you do not need to redeploy the API. https://hubbo.ioandhttps://www.hubbo.io.- The Hubbo admin app (
https://app.hubbo.io) for in-app previews.
The embed always sends your account key in the Hubbo-Project-Key header (and on WebSocket connection_init). Cookies alone are not enough to read or change project data. Allowed request headers include Content-Type, Authorization, Apollo-Require-Preflight, Hubbo-Project-Key and Hubbo-Chat-Token. Methods are GET, HEAD, PUT, PATCH, POST, DELETE and OPTIONS.
Third-party cookie restrictions
Because the cookies are set by api.hubbo.io while the visitor is on your domain, they are third-party cookies. Browsers that block third-party cookies by default, or visitors who block them in settings, can prevent Hubbo from identifying the account. If your analytics show fewer widget impressions than expected in privacy-focused browsers, this is a likely reason.
Do not proxy or rewrite the embed
Do not put a reverse proxy in front of api.hubbo.io/embed or strip cookies from its responses. The embed relies on the API host setting its own cookies and on the CORS configuration above.
Privacy and consent
Cookie consent requirements depend on your jurisdiction and your own policy. See GDPR and privacy for what Hubbo stores, so you can reflect it in your cookie notice.