API Maker

The backend engine for the AI era

MaskingEpisode 35 3:28 9 chapters October 2026

Database Name Masking: One Name in Code, Any Database per Developer

Your code names the production database, while your laptop, your staging server and your teammates have other copies. Database name masking keeps one name in the code and lets each account map it to another database: the same address, every API following the mask, and nothing committed to Git.

In the playlists The complete course Migrations & tenants

Chapters

What you will learn

  • One database name in the code
  • A mask, set in User Info
  • The same address reads another database
  • The Databases panel, and what follows the mask
  • Removing a mask
  • One name for people and AI assistants
In the docsMask database names
Transcript485 words · click a time to play from there

Intro

Your code names the production database. Your laptop, your staging server and your teammates have other copies. Database name masking keeps one name in the code, and lets each account map it to another database.

Database names, the usual way

Usually, database names live in environment files, someone renames them before every pull request, two developers on one server write into the same tables, and code written by people or by AI hard codes the name of an environment. With API Maker, the code and git keep the production name, each account maps it to its own database, and every API follows the mask. In this video : one name in the code, many on servers, the same address before a mask, a mask in User Info, the same address after it, what follows the mask, and removing it.

One name in the code

The code, its schemas and git name the database sales. Production reads sales. Nisha reads her own copy, sales underscore nisha, and Daniel reads sales underscore daniel, on the same MySQL server. Nobody renames anything : the mask lives on the account, not in the code.

The same address

First, a token of the API user of the account. Then the orders of sales : one hundred and eighty of them, CH 2026 0001 and on.

A mask in User Info

The user menu, User Info, and its section Masked Database Names : none yet. Add. The instance : mysql, the name in the code, sales, and its name on this server, sales underscore nisha. Add : the row is new, and not saved yet. Update User Info.

The same address (2)

The same address again, not one character changed : two orders, Nisha's test orders. The API read sales underscore nisha. The Databases panel of mysql lists sales, with a mask. Its tooltip gives the name on this server. The real sales is hidden from this account. Its tables are the tables of the copy.

What follows the mask

Every generated API follows the mask, and so do the custom APIs and hooks that call g dot sys dot db. Index Maker works on the masked database too. Git never carries a mask, in a commit or a pull. SQL text you write yourself is not changed, and the security report says when a mask is in use. To go back, delete the row, confirm, and update. The same address reads the one hundred and eighty orders of sales again.

One name for people and AI

The production name is the only name in the code, and in git. Code an AI assistant writes uses that name too, and still runs on each developer's copy. Each copy is a database of its own : the user of the instance needs rights on it, as on any database.

Recap

To sum up. One database name in the code. A mask per account, set in User Info. The same address reads another database. Every API follows it, git never carries it. Next : API Testing in depth. API Maker. Build faster, spend smarter, deliver better.