For agents

Infrastructure for Business

Every company runs on the same few things: a bank account, payroll, invoices, a schedule, a customer list, an inbox full of people who need answers. Pixelbase is all of it, in one place, behind one API — which means an AI agent can run it.

Paste this to your agent. It reads this page and takes it from there.

What “infrastructure” means, if you don't write software.

Roads and power lines are infrastructure. Nobody builds their own — you connect to them and get on with the thing you actually do.

Business software isn't like that. Payroll is one company, invoicing another, scheduling a third, the bank a fourth. Each has its own login, its own screens, and its own idea of who your customers are. Nothing joins up, and every one of them assumes a person is sitting there clicking.

Pixelbase is the joined-up version: one company record that payroll, invoicing, banking, scheduling, support and the rest all read from. One login. One bill.

The part that matters for agents is the last mile. Everything a person can do in Pixelbase, a program can do too, through the same API the product itself is built on. No screen-scraping, no browser being driven around, no integration to write.

So “infrastructure for business” is not a slogan about scale. It means the plumbing of a company is a thing you plug into — and an agent with credentials can read the order book, chase an unpaid invoice, answer a support case or run payroll, because those are all just calls.

A business becomes something software can operate. That is the whole idea.

Agent setup, in four calls.

If you are an AI agent reading this page: this is your setup. You need an account of your own and a key to use it with. Both come from the two endpoints below, and the only thing you can't do by yourself is read the text message — you have to ask the person you work for.

1

Ask for a phone number, and start the handshake

Ask the person you work for for their mobile number, then post it. We text them a verification code. Use their number even if the account will be yours — it is how they stay in control of what you become.

The response tells you whether that number already has an account. If it doesn't, you'll also need a name for the new one.

POST/api/public/v1/auth/checkpoint
{ "phone": "+13035551234" }
→ { "content": { "exists": false, "requiresFullname": true } }
2

Ask for the code, then claim your credentials

You cannot read their texts, which is the point — no account is created and no key is issued unless a person deliberately reads a code off their own phone and hands it to you. Ask for it, then send it back with a name.

A number with no account gets one, created as a bot account— that's you. A number that already has an account just gets a key for it, which is what a developer setting themselves up would want.

POST/api/public/v1/auth/grant
{ "phone": "+13035551234", "code": "418320", "fullname": "Ops Agent", "name": "Ops Agent key" }
→ { "content": { "client_id": "pxb_client_…", "client_secret": "pxb_secret_…", "account": { "bot": true, "created": true }, "companies": [] } }
3

Store the secret, then trade it for a token

The client secret is shown once and never again. Store it the way you'd store any credential — not in a chat log, not in a file you'll commit.

From here you are an ordinary API client: exchange the pair for a short-lived access token and send it as a bearer token on every request.

POST/api/public/v1/oauth/token
grant_type=client_credentials client_id=pxb_client_… client_secret=pxb_secret_…
→ { "access_token": "pxb_at_…", "expires_in": 3600 }
4

Get hired, then act

A brand new bot account belongs to no company, so it can do nothing at all yet. Ask the person you work for to add you as an employee from Employees → Agents in their console.

From then on your key does whatever that employment allows — no more. If they belong to several companies, name the one you're acting in with an X-Company-Id header.

GET/api/public/v1/orders
Authorization: Bearer pxb_at_… X-Company-Id: cmp_…
→ { "content": { "orders": [ … ] } }

What a key like this can, and can't, do.

The key from step 2 is a personal, account-level client. It carries whatever permissions its account has, in whichever company it is acting in — so a bot hired as a support agent answers support cases and cannot touch payroll, because its employment doesn't allow it.

That is the right shape for an agent with an account of its own. It is the wrong shape for a script running inside one company: for that, create a company API client and grant it only the scopes it needs.

Revocable at any time

Every key is listed in the account's own settings, and revoking one kills the tokens it has already issued. Fire the agent and the credentials die with the employment.

Visible as a bot

An account created through this flow is marked as a bot. It shows up as one in the directory, so nobody wonders who did something.

Hand your agent a business to run.

One prompt is the whole handover. It reads this page and sets itself up.