Sign in
Catentio uses Huudis identity. Email + password is checked directly against Huudis without leaving catent.io — the login form posts your credentials to the portal's own backend, which authenticates against Huudis and comes straight back. Google / Apple do redirect: the portal sends you to Huudis, Huudis authenticates you there, and Huudis sends you back. Either way, the portal then checks your identity against its allowlist before it lets you in.
The whole flow takes a few seconds once you've typed a password, or is effectively instant if Huudis already has an active session for you (social path).
You won't be able to sign in unless your Huudis identity is on the deployment's allowlist. See the Authentication overview for the gate. If sign-in fails with "Access is restricted" (password path) or you're bounced back to
/loginafter a social sign-in, that's the allowlist rejecting you — not a transient error.
When to use this
Use the standard sign-in flow when:
- You're opening the Catentio portal in a browser for the first time on a new device.
- Your session cookie has expired (after 7 days of inactivity).
- You explicitly signed out and want to come back in.
For automation, you don't want this flow — use API authentication with a static key, or the CLI's device flow.
The flow
- Visit
catent.io. - Click "Log in".
- Enter email + password (checked in place), or click Google / Apple (redirects to Huudis and back).
- You land on
/dashboard.
Step-by-step
1. Visit catent.io
Go to catent.io. The landing page shows the marketing site. Click Log in in the top-right.
(If you go directly to a /dashboard/* URL and you're not signed in, the portal will redirect you to /login automatically and bounce you back to the original URL once you authenticate. You don't need to remember the page you wanted.)
2. Click Log in
You land on catent.io/login. The page shows two options:
- An email + password form.
- Optionally Continue with Google and Continue with Apple — these buttons only render if the Huudis instance has the corresponding providers configured. Catentio probes Huudis on page load and conditionally renders them.
Submitting the email + password form POSTs directly to the portal's /api/v1/auth/login route. That route calls Huudis's token endpoint server-side (Resource Owner Password Credentials — your credentials never leave catent.io), decodes the returned identity, checks it against the allowlist, and on success sets the catentio_session cookie and redirects the page to /dashboard. On failure it shows an inline error ("Incorrect email or password", or "Access is restricted." if you authenticated fine but aren't on the allowlist) — no redirect happens.
Clicking a social button starts the OIDC flow instead: the portal calls /api/v1/auth/huudis/start, which generates a PKCE pair and redirects to huudis.com/api/v1/oidc/authorize.
3. Authenticate with Huudis (social sign-in only)
You're on huudis.com now, going through the chosen provider's consent screen.
If Huudis already has an active session for you — e.g., you signed into Plugipay earlier today — this step is silent. You don't see Huudis at all; the flow auto-completes and you're back on Catentio.
Otherwise: authenticate with the provider, and Huudis redirects you back.
4. The callback (social sign-in only)
The browser arrives at catent.io/callback?code=…&state=…. The callback page POSTs the code + state to /api/v1/auth/huudis/callback, which:
- Reads the PKCE cookie set in step 2.
- POSTs the code + verifier to Huudis's token endpoint.
- Decodes the returned id token's claims and checks
subagainst the allowlist (HUUDIS_ALLOWED_USER_IDplus anyHUUDIS_ALLOWED_USER_IDS). - If matched, sets the
catentio_sessioncookie; the callback page then routes you to/dashboard.
If the gate rejects you, the response is a plain 403 (no redirect with an error code) and the callback page sends you back to /login.
5. The dashboard
You land on /dashboard. The top-left shows your active workspace; the sidebar groups every section into Overview, Operations, Platform, Monitoring, Connections, and Account.
From here, see Portal → Tour for the full section-by-section layout.
Programmatic sign-in (CLI / scripts)
The portal cookie flow is browser-only. If you want a non-browser session — the CLI or an interactive script — use OIDC device flow instead:
catentio-saas auth login
The CLI prints a verification URL + code, opens your browser, and polls Huudis for the token. The flow uses your same Huudis identity (and goes through the same allowlist gate), but the credentials are stored at ~/.catentio-saas/credentials rather than in a browser cookie.
See API authentication for the underlying protocol and how to wire device flow into your own code via the SDKs.
Common errors
"Access is restricted." / 403 not_authorized
You're a valid Huudis user, but your sub isn't on the deployment's allowlist (HUUDIS_ALLOWED_USER_ID / HUUDIS_ALLOWED_USER_IDS). There's no client-side fix — either the deployment operator adds your identity server-side, or you contact them.
invalid_state
The PKCE state didn't match between authorization and callback. Usually caused by:
- A stale tab where the original PKCE cookie expired.
- Opening multiple sign-in flows in parallel.
- Clearing cookies mid-flow.
Start over by going back to catent.io/login.
token_exchange_failed
The portal couldn't exchange the code at Huudis. Either Huudis is having a bad day (rare) or your client config is wrong (rarer once the deployment is live). Refresh and try again; if it persists, check the Huudis status page.
Bounced back to /login
You opened a /dashboard/* URL without a valid session cookie. The portal's middleware redirects you to /login and remembers where you were headed, so you land there after signing in. A portal API hit without the cookie just gets a bare 401 (no JSON error body).
Next
- Forgot password — reset a Huudis password.
- Authentication overview — the protocol-level picture.
- Portal → Tour — what you can do once you're in.