API Maker

The backend engine for the AI era

Dev accountsEpisode 42 3:24 8 chapters October 2026

Developer Accounts: A Workspace for Every Developer on One Server

A team builds one backend together. With developer accounts, every developer gets a workspace of their own on the same API Maker server, with their own API path, secrets and masks and their schedulers paused, and their work reaches the team through Git.

In the playlists The complete course Developer workflow

Chapters

What you will learn

  • Who may do what
  • A developer, added on the Dev Account page
  • One server, a workspace each
  • The panel of a developer
  • How work flows back, through Git
In the docsDeveloper accounts
Transcript493 words · click a time to play from there

Intro

A team builds one backend together. With developer accounts, every developer gets a workspace of their own on the same API Maker server, and their work reaches the team through git.

A team, the usual way

Usually, a team shares one login, so nobody knows who changed what, overwrites each other's work on one environment, or installs the whole stack on every laptop. And a test scheduler can email real customers. With API Maker, each developer signs in to a workspace of their own, with their own API path, secrets and database copies, their schedulers never run in the background, and their work reaches the team through a branch and a pull request.

In this video : who may do what, a developer added by the admin, one server, a workspace each, the panel of a developer, and how work flows back to the team.

Who may do what

An admin owns the account of the project. A developer is made by that admin, and works in a workspace of their own : their own APIs, secrets and masks, the sandboxes, logs and analytics of the admin, and schedulers that never fire. Only the admin manages developers and licenses.

A developer, added

Nisha is the admin of Calm Home. Dev Account, in the Security panel : no developer yet. Add one : Daniel Okafor, the email he signs in with, a password, and an API path, the part of every URL of his APIs. Save : his workspace is made, with its defaults and sample data, and his card is on the page.

A workspace each

One API Maker server. Nisha's account holds the project : its instances, APIs and the git repository. Daniel works under his own path, with his own secrets and his own copy of each database, masked to the names of the code. A second developer gets the same, without touching either of them.

The panel of a developer

Now Daniel signs in. His dashboard looks like Nisha's, but the Security panel has no Dev Account, and there is no Licenses page. His user menu has User Info, for his masked databases, the sync token of the local client, and Restart All Sandbox, but not Restart All Process. His instances : only the sample of his new workspace. The project comes to him through git.

How work flows back

Daniel pulls the branch of the team into his workspace, and works on a branch of his own. His schedulers never fire, so a test can not email a customer. He commits from the Git page, and opens a pull request, reviewed like any other code, including code an AI assistant wrote. When it is merged, Nisha pulls it into the account of the project.

Recap

To sum up. The admin adds developers on the Dev Account page. Each one gets a workspace of their own on the same server. Their schedulers never run, their databases are their own copies. Work reaches the team through git and pull requests. Next : the root user and admin accounts. API Maker. Build faster, spend smarter, deliver better.