# Create your company and first application Sign up, create a company, add an application with Development and Production, and add your first LLM gateway. Source: https://tokentriage.com/docs/get-started/first-company --- import Details from '../../../components/Details.astro'; import NextSteps from '../../../components/NextSteps.astro'; 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. {/* Retained live setup and return-sign-in evidence: docs/manual-testing/foundation/S02/receipt.md, S02 D live journey re-run, and screenshots/foundation/S02-20260921T2226Z-09-live. */} ## 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](/docs/build/organizations-and-access) 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.
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`: ```json { "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. ```text 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.
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](/docs/build/organizations-and-access). - Giving TokenTriage a provider key, once: [Add a saved provider connection](/docs/build/provider-connections). - Configuring routing, testing a draft and promoting it: [Configure, test and promote a gateway](/docs/build/gateway-builder). - Pointing an existing OpenAI client at a gateway: [Connect your app](/docs/get-started/connect-your-app).