There are two real ways to create a brand-new Organization at /signup: Google, or the direct multi-step
form (email/username/name, then date of birth/gender/country/phone — POST /api/v1/users/signup/, one all-or-nothing
submission, nothing created until the final step succeeds). The direct form creates the
account passwordless — no password is ever set —
and finishes by pointing you at magic link, email OTP, or Google as real, working
sign-in methods for that new account. Password, magic link, and email OTP on their own still cannot create an Organization —
they all require an existing account already in one; only Google and the direct form
above actually provision a new Organization. Either path starts the new Organization on
the free plan (2 Applications, 10,000 monthly
active users — see Billing & plans for the full real catalog), with its creator as Owner,
holding every global Permission on that Organization. See Sign-in methods for how each method itself works once an account exists.
An Application is a client that your Organization's users sign into — a real product, not this dashboard itself (the dashboard has its own Application row, but it's auto-provisioned and never appears in this list). Register one from the Applications page, or directly:
POST /api/v1/applications/
Authorization: Bearer <access_token>
Content-Type: application/json
{
"name": "Forge",
"client_type": "confidential",
"redirect_uris": ["https://forge.example.com/callback"],
"allowed_grant_types": ["authorization_code"]
}The response includes client_secret — shown
exactly once, for a confidential client.
There is no way to retrieve it again afterward; a public client (a browser-only app that can't
hold a secret) never gets one, matching PKCE's own security model.
Every Application also gets a slug, generated
from its name — it names the Application's own <slug>:app.access Permission, covered on
the Roles & permissions page.
Every Application is private by default — is_public is false until you set it. A public Application also has a home_url (where it actually lives — distinct
from redirect_uris, which are OAuth callback
targets, not a page anyone should be linked to directly):
PATCH /api/v1/applications/{id}/
{ "is_public": true, "home_url": "https://forge.example.com" }Once set, the Application appears — name, logo_url, home_url, nothing else — on a real, public, unauthenticated endpoint, scoped to this
Organization's own slug:
GET /api/v1/organizations/{org_slug}/public-applications/
[{ "name": "Forge", "logo_url": "https://...", "home_url": "https://forge.example.com" }]No client_id, no slug,
no OAuth-relevant identifier is exposed here — this is a pure "what can I launch"
list, not a way to start a sign-in flow. It's a general platform capability, not
specific to any one Organization: any Organization's own slug works the same way,
rate-limited the same as every other public discovery endpoint in this API.
Every one of the four official SDKs (Django, Node.js, PHP/Laravel, Go — see Integrate) ships a typed client method for this endpoint. No OAuth flow, no PKCE, no session — it's a plain, unauthenticated call any of them can make at any time, for any Organization's slug:
# Python (Django SDK)
apps = client.get_public_applications(org_slug="onehux")
// Node.js/TypeScript SDK
const apps = await client.getPublicApplications({ orgSlug: 'onehux' });
// PHP/Laravel SDK
$apps = $client->getPublicApplications('onehux');
// Go SDK
apps, err := client.GetPublicApplications("onehux")pip install onehux-sso · npm install @onehux/sso · composer require onehux/sso · go get github.com/Onehux/onehux-sso-go
Each returns the same three fields (name, logo URL, home URL) in that SDK's own naming convention. Rendering is deliberately left entirely to you — none of the four SDKs ship a launcher UI component. Every integrator has their own design system, and a pre-built component would either not match it or need replacing immediately, which is a worse outcome than no component at all. Each SDK's own README has a plain, unstyled example loop showing how to render the result — explicitly meant to be adapted, not used as-is.
From your Organization's own Settings page — "Danger zone," covered in full on Settings & branding. Deactivating is a reversible status change; deleting is real and requires typing the Organization's exact name to confirm. Both are hard-blocked, at the API level, for the two reserved platform-internal Organizations — never reachable through this feature no matter who's asking.
If the Organization you delete happens to be your own home Organization (the one every personal signup creates for its own creator), you are not permanently locked out: the next time you sign in through the default OneHux Accounts login, a fresh personal Organization is silently minted for you and your account is repointed at it — the same shape a brand-new signup gets, with a one-time notice explaining what happened. This only ever applies to your own account-anchoring Organization, never a business workspace you merely have a Membership in.
SAML 2.0 and SCIM 2.0 relying parties are not supported — every Application here is an
OIDC-shaped Authorization Code + PKCE client. allowed_grant_types is stored but not yet enforced by the OAuth flow itself.