Create your company and first application
Sign up, create a company, add an application with Development and Production, and add your first LLM gateway.
On this page
In this tutorial we’ll turn an allowlisted sign-up into a company with one application inside it, two environments, and an LLM gateway waiting for its first configuration.
Everything happens in a browser. You won’t install anything, write code, or paste a provider API key on this page.
One thing to settle before you start: this deployment is a private test. Sign-up accepts allowlisted email addresses only, and every commercial flow runs against test billing, so the plan on your company home is a test-mode plan and no card is charged.
What you need
Read the second column before the first, because half of this table is about what you can leave closed.
| Thing | Needed? | Why |
|---|---|---|
| an allowlisted email address | yes | sign-up is closed while the deployment is a private test |
| a mailbox you can open now | yes | verification sends a one-time link, and it gates company creation |
| a browser | yes | the whole path is in the portal |
| a provider API key | no | provider keys are added later, once, on a workspace’s connections page |
| a payment card | no | commercial flows run against test billing |
| a terminal, a config file, an installed binary | no | nothing here is self-hosted |
Allow time to open the verification email and set up your authenticator. Company creation and return sign-in were checked in the private deployment on September 21, 2026; that observation does not promise how quickly your email will arrive.
The words on the screen
Six nouns carry this page. Each is defined again where you meet it, so you can skip this table and come back to it.
| Word | What it means |
|---|---|
| organization | the company; it owns people, workspaces and billing, and it is what you create in step 2 |
| workspace | where related resources and their isolation settings live: environments, applications, gateways and saved provider connections |
| team | a group of people inside the organization; changing a team’s roster moves no application data |
| application | one of your programs, such as a customer portal, holding the LLM gateways it calls |
| LLM gateway | a persistent endpoint with its own routing and protection configuration, independent of the model or key it currently uses |
| environment | a named deployment target inside a workspace, such as Development or Production, with its own applied configuration and its own credentials |
Who can do what in your company takes these apart properly. This page uses them.
1. Sign up and verify your email
Nothing else works until the session is verified, so this is step one rather than a prerequisite.
Open the portal, enter your allowlisted address and set a password. The form creates your login and sends a one-time verification link to that address. Open the link in the same browser.
You know it worked when the link returns you to the portal signed in, and the portal offers to create a company rather than showing a list of companies you already belong to.
If the verification email doesn't arrive
Ask for a resend from the portal, then check the folder your mail provider files unfamiliar senders into. Verification links expire, and a resend issues a fresh one rather than reviving the old one.
A message naming the private test on the first screen, before any email is sent, is a different problem: that address isn’t on the allowlist. No amount of resending fixes it.
2. Create your company
A company is the container every later grant hangs off, so it comes before people, applications and keys.
Enter a display name, such as Acme. The portal derives a URL slug from it and lets you edit the
slug before you commit. Slugs are lowercase letters, digits and hyphens.
One submission creates five things together: the organization, your membership in it, an org_owner
role binding for you, a default workspace, and that workspace’s Development and Production
environments. If any part fails, none of it lands.
The form posts this body to the customer API’s organization-create operation, POST /portal/api/v1/customer/v1/organizations:
{ "display_name": "Acme", "slug": "acme" }
That block describes the supported request shape; it is not a captured payload. The private
browser journey verified company creation and the resulting hierarchy. A success answers 201
with the hierarchy it created, and a slug somebody already holds answers 409.
You know it worked when the company home loads and its heading carries the display name you typed.
3. Read your company home
The first screen is a setup path rather than a dashboard, because there is nothing to chart yet.
Welcome to Acme
Add your first application
Invite the people who will manage it
Connect an application and see its first request
Compare its cost and quality before changing its model
Company plan: test mode
That block summarizes the setup path observed in the private browser journey; it is not a screenshot. The plan line reads your default workspace’s billing state. The Test billing marker identifies this deployment’s test-mode billing.
You can start an application before finishing every company setting. Optional products you haven’t enabled don’t fill the navigation with disabled choices.
4. Add the first application
An application is the unit your people get access to, so creating one is what makes delegation possible later.
Choose Add application and name it, say User Portal. The portal derives a slug, unique within
the workspace. The application lands in your default workspace, which is the common path; splitting
departments across separate workspaces is a later decision.
Creating an application enables every active environment in the workspace, so this one starts with both Development and Production.
You know it worked when the application home offers three actions under What you can do here: Add an LLM gateway, Manage access and Connect this application. The third goes to the workspace’s provider connections page, which is where a provider key is deposited once.
If the slug is already taken
Application slugs are unique per workspace, and the create answers 409 with a problem document
naming the conflict. Edit the slug, or pick a display name that derives a different one. The display
name itself doesn’t have to be unique.
5. Look at Development and Production
These two arrived with your workspace, and knowing what they are stops the most common wrong assumption about them.
| Environment | Selector | Protected | Where it came from |
|---|---|---|---|
| Development | development |
no | created with the workspace |
| Production | production |
yes | created with the workspace |
Both are ordinary rows, not a two-value enum. Find them under Environments on the application home, each with its display name, its selector, a Protected badge where the row carries one, and a state chip. An authorized administrator can Add environment there for QA or Staging, and can Rename one. Renaming Development grants no production rights, and renaming the protected environment doesn’t remove its protection: protection is a field, not a name.
A new environment takes a name and a selector, and the selector is permanent. Whether deploying there needs protected-environment permission is chosen at creation, because neither the selector nor the protected flag can be edited afterwards.
Each environment holds its own applied configuration and its own credentials. You pick which environment you’re editing before a change can affect its traffic.
6. Add the first LLM gateway
A gateway is the thing your code calls, so this step gives your application an address to grow into.
Open the application and choose Add LLM gateway. Give it three values: a code such as A1, a
name such as Helpdesk chatbot, and a purpose such as answers support questions. The code is
unique within the application. Requests select the gateway by its assigned gateway ID, which is
separate from this display code.
One gateway per separately managed use case is the default. Several call sites in the same application can share a gateway when they should share its behaviour and its reporting. Your application still supplies the messages that make a gateway a chatbot or a classifier.
You know it worked when the gateway page opens on Overview, with an environment picker in its header and a chip reading “Current deployment: not deployed”. The picker offers your workspace’s own environment rows rather than a fixed pair, and it sits above the tabs so it is never ambiguous which environment a change is about.
The gateway has seven working tabs: Overview, Configure, Test, Compare, Requests, History and Connect. Their contents depend on your permissions and the gateway’s saved configuration and traffic. A new gateway can have empty results. In Test, inspecting a route calls no provider; Run & save is a separate paid action. Use Connect for the application’s request settings after a release is applied.
What this tutorial doesn’t cover
Four things you’ll want next, each on its own page:
- Inviting people, teams and what each role can do: Who can do what in your company.
- Giving TokenTriage a provider key, once: Add a saved provider connection.
- Configuring routing, testing a draft and promoting it: Configure, test and promote a gateway.
- Pointing an existing OpenAI client at a gateway: Connect your app.