Documentation/Getting Started/Create Your Account

Create Your Account

Sign up for Supero in a browser: what the form asks for, how email verification works, what a new account actually contains, and what to do in the first ten minutes.

What Signing Up Gives You

Signing up creates a workspace, not just a login. One form produces the whole top of the Supero hierarchy, plus the credentials to work with it.

What is created	Name	What it is
A domain	The organization URL you choose	The top of the hierarchy. Everything you build lives under it, and it is part of every API path you will ever call.
A project	default-project	One application environment: its own schemas, its own generated API, its own tenants.
A tenant	default-tenant	The workspace tenant, meant for you and your staff. Your app's real customers get their own tenants later.
Your user account	The email you signed up with	Created with the domain_admin role — full access to everything in the domain, including billing.
An admin API key	Returned in the response	A server-to-server credential scoped to the new domain, for the SDK, the CLI, and MCP.

You do not have to create a project or a tenant before you can build. The defaults are real and immediately usable — see Core Concepts for what each level does.

ℹ️ One domain per email address

A given email address owns one domain. Signing up again with the same address, for a second organization, is refused rather than creating a second workspace. If you need a genuinely separate top-level account, use a different email or talk to us at [email protected].

Before You Start

•An email address you can read right now — a verification code is sent to it during signup and expires in ten minutes.
•A name for your organization. The URL for your workspace is derived from it, and that URL is permanent.
•A password of at least 8 characters, containing at least one lowercase letter, one digit, and one special character.

Nothing else. There is no payment method, no plan selection, and no cloud account to connect at signup.

Sign Up

The console lives at app.supero.dev. Go to app.supero.dev/register directly, or open the login page and use the "Sign up" link at the bottom.

1
Full Name
Your own name. It becomes the display name on your user account.
2
Email
Where the verification code is sent, and the address you will log in with.
3
Password and Confirm Password
The form checks that it is at least 8 characters and that both fields match.
4
Organization Name
Your company or team name, in whatever capitalisation you like — "Acme Corporation".
5
Organization URL
Filled in for you from the organization name, shown as your-name.supero.dev. Click "Edit organization URL" if you want to set it yourself. This is the value that becomes your domain, and it is permanent.
6
Agree to the terms
The consent line covering the Terms & Conditions, Mutual NDA, and Privacy Policy is ticked by default; each document opens in a new tab.
7
Create Account
Submits the form and sends the verification code.

⚠️ The form checks less than the platform does

The signup form validates password length only. The full rule — at least 8 characters with a lowercase letter, a digit, and a special character — is applied when the account is actually created, which happens after you enter the emailed code. A password like "password1" gets past the form and is then rejected at the last step, so pick one that satisfies the full rule up front.

Choosing Your Organization URL

This one field deserves a moment's thought, because it is the only decision on the form you cannot undo.

🚨 The domain name is permanent

There is no rename. A domain's display name, logo, colours, contact details and custom domain can all be changed later from workspace settings — its name cannot. The name is baked into every API path (https://api.supero.dev/api/v1/crud/{domain}/{type}), into every record's fully-qualified name, into the API keys you mint, and into the hostname of every app you publish. Choose something you will still want in a year, and prefer your organization's name over your first project's name.

The value is auto-derived from your Organization Name: lowercased, spaces turned into hyphens, anything else stripped, and truncated to 30 characters. Editing it by hand is normal — the derived value is a starting point, not a recommendation.

Rule	Detail
Characters	Lowercase letters, digits, and hyphens only. No spaces, no dots, no uppercase.
Length	At least 3 characters, and no more than 63.
Start and end	Must begin and end with a letter or a digit, not a hyphen.
Uniqueness	Globally unique across the whole platform, not just within your organization.
Reserved	A set of platform names is refused: www, api, app, admin, status, ai, connectors, docs, dev, staging, prod, production, test, demo, preview, mail, ftp, cdn, assets, static, internal, system, supero, root, kubernetes, k8s — as is anything starting with sbx-.

💡 Availability is checked late, not as you type

The form does not tell you a name is taken while you are filling it in. Uniqueness is resolved at the end of the flow, after email verification, so a clashing name surfaces as an error on the last step rather than the first. If a name matters to you, be ready with a second choice.

Verify Your Email

Every browser signup is gated on an emailed code. Submitting the form does not create anything yet — it sends a code and moves you to the verification screen.

Property	Value
Code format	6 digits
Valid for	10 minutes
Verification attempts	5. After the fifth wrong code the pending signup is discarded and you start the form again.
Resending	The screen offers a resend after a 60-second cooldown.
Resend ceiling	At most 3 codes to the same address in any 10-minute window. Beyond that the request is refused with HTTP 429 until the window rolls over.

The six boxes accept a pasted code as well as typed digits, and the screen submits itself as soon as the sixth digit lands. The verification screen can only be reached by completing the signup form — opening it directly sends you back to the form.

Once the code is accepted, your domain, project, tenant, user, and API key are created in a single step and you are signed in immediately. There is no second login.

ℹ️ Not receiving the code

Check spam first. If a signup returns successfully but no mail arrives, the response says so rather than pretending it was delivered — the screen still lets you resend. If three resends produce nothing, the address is likely on a suppression list; write to [email protected] with the address and the approximate time.

Signing Up with Google

Where Google sign-in is configured for the deployment you are using, the login and register screens show a Google button. If it is not configured, the button is not rendered at all — its absence means unavailable, not broken.

Google shortens the flow but does not replace it. Authenticating with Google returns you to the signup form with your name and email filled in and the email field locked, and you still have to:

•Choose an Organization Name and Organization URL.
•Set a password anyway — it is what the CLI, API keys, and platform downloads authenticate against.
•Enter the emailed verification code. Signing in with Google does not skip it.

Once your account exists, the Google button on the login page signs you straight in. For team members authenticating through a company identity provider instead, see Users & Roles.

What Happens After

You land on the console dashboard, signed in as a domain_admin of your new domain. A welcome panel appears while you have no projects yet, laying out the same four steps the console is organised around: create a project, define your data models, generate SDKs, and deploy the backend.

Your session carries an 8-hour access token and a 7-day refresh token. Because your role is domain_admin, the login response also carries an API key you can use for server-to-server calls — see Authentication for both credential types and how they differ.

⚠️ The console is for builders, not for your app users

app.supero.dev is where you build. The people who use the application you build sign in to the app itself, not to the console — a tenant-scoped account that tries to open the console is signed straight back out. Create your customers' accounts inside your app, and see Admin vs Customer Views for how the two surfaces differ.

What to Do First

The most useful first move is deciding how you want to build, because Supero supports several genuinely different approaches and it is easier to pick up front than to switch later.

Start here

Pick a path

Five ways to build — describe it in App Studio, drive it from your AI editor, model the schema first, start from data you already have, or wire up external services. Ways to Build

Ten minutes

Make the API do something

Background

Learn the vocabulary

Domain, project, tenant, namespace, schema, record — and how they nest. Core Concepts

Before customers

Plan your tenancy

Decide now whether your app serves multiple customers, and where each one goes. Building Multi-Tenant Apps

🚨 default-tenant is for you, not for your customers

The tenant created with your account is the workspace tenant, and membership of a tenant named default-tenant grants project-wide access across every tenant in that project on the tenant name alone, regardless of role. That is correct for your own staff and wrong for anyone else. Before you onboard a real customer, create a dedicated tenant for them — see Building Multi-Tenant Apps. It is much easier to do this before there is data than after.

Plans and Billing

There is no plan selection during signup and no card to enter. A plan is assigned to your new domain automatically, and you can build, generate apps, and run previews on it straight away.

One thing to know before you promise anyone a URL: publishing a permanent live deployment requires a plan that includes one, and the lower tiers are build-and-preview only. Going live without an allowance returns an upgrade prompt instead of starting a build. Check what your domain is on from the Billing screen in the console, and see Plans & Billing for the catalog and Publish Your App for the publishing flow.

If Something Goes Wrong

What you see	What it means	What to do
"Already registered. Please login." with a success status	That email already owns that domain. Nothing new was created and nothing was overwritten — re-registering an existing account is treated as a no-op rather than an error.	Go to the login page. Use the password-reset flow if you no longer have the password.
The organization URL is already taken	Domain names are globally unique and someone else has it.	Pick another. The name cannot be reclaimed or negotiated for through the form.
Your email already has a workspace	One email address owns one domain, and yours already belongs to a different one.	Sign up with a different address, or ask the owner of the existing domain to invite you into it as a team member.
A password error after you entered the code	The password passed the form’s length check but not the full rule.	Start the form again with a password containing a lowercase letter, a digit, and a special character.
The code will not verify	It has expired (10 minutes), or you have used all 5 attempts.	Resend from the same screen. After 5 failed attempts the pending signup is gone and you re-submit the form.
HTTP 429 while resending	More than 3 codes were requested for that address within 10 minutes.	Wait for the window to roll over rather than retrying immediately.

Anything else, or a signup that appears to have half-completed: write to [email protected] with the email address, the organization URL you tried, and roughly when.

Creating an Account Without the Browser

The browser flow is not the only way in. Two registration endpoints exist and they behave differently, which is worth knowing before you script anything.

Call	Behaviour
POST /api/v1/auth/register	What the console uses. Sends a verification code and returns an action of verify_email; the account is created by the follow-up POST /api/v1/auth/verify-email with the code. Duplicate-name and password checks run at that second step, not the first.
POST /api/v1/domains/register	The direct path used by the SDK and the Quick Start. Creates the domain and its admin user in one call, with no emailed code. Re-sending an identical registration is idempotent rather than an error.

ℹ️ The storage backend is chosen once

The signup form does not offer a choice of storage backend, so browser signups use the default. The direct registration call accepts an optional db_type of mongodb or postgresql, and that choice is fixed for the life of the domain — it cannot be changed afterwards. If it matters to you, register through the API.

Either way you end up in the same place: a domain, a default-project, a default-tenant, and a domain_admin user.

Next Steps

•Ways to Build — the five entry points into building an app, and which one fits how you work.
•Quick Start — domain, project, schema, and your first CRUD call from a terminal.
•Core Concepts — the domain/project/tenant model and how records are addressed.
•Workspace, Domains & Tenants — API keys, team members, and what else lives under your domain.
•Users & Roles — inviting your team, the role catalog, and sign-in flows.

Next →What is Supero

On this page