Every capability is an interface first, and a screen second
There is nothing you can do in the console that you cannot do over the API. That is a design rule rather than an aspiration, and it is what allows an agent to run real work here instead of describing it.
The four ways in
Pick the one that fits, or use all of them. They reach the same records under the same permissions.
- Bearer authentication with scoped keys
- A published specification describing every operation and its rules
- Consistent conventions for filtering, pagination and errors
- Credentials are never returned, including in responses that would otherwise echo them
- Around forty commands covering the whole platform
- Every command outputs JSON
- A generic call and post for anything not yet wrapped
- Configured with two environment variables
- Point any compatible agent client at it with two settings
- Each tool maps to an API operation with typed arguments and a description
- Permissions come from the key, so the tool list is the permission list
A request, and what comes back
Authenticate with a scoped key and ask for identity. Everything else follows the same shape.
curl -H "Authorization: Bearer $ALPHAFLUX_API_KEY" \
https://alphaflux.net/api/me
{
"email": "you@example.com",
"roles": ["owner"],
"tenants": [
{
"name": "Northside Services",
"role": "owner",
"plan": "growth",
"modules": ["phone", "field", "crm", "inventory", "billing", "email"]
}
]
}The same thing from the command line
JSON out, so it composes. The last two commands reach any endpoint, including ones that do not have a typed command yet.
export ALPHAFLUX_API_KEY=afx_...
export ALPHAFLUX_BASE=https://alphaflux.net
alphaflux me
alphaflux field jobs add --customer "Acme LLC" --service "Treatment" --date 2026-10-02
alphaflux field status --id fs_job:abc123 --status done
alphaflux phone text --to +15095551234 --body "On the way"
alphaflux billing run
alphaflux key create --label dispatch-agent --scopes "field:write,phone:read"
alphaflux call api/dashboard
alphaflux post api/notes --json '{"account":"fieldroutes:10000","body":"Called back, no answer"}'How keys and scopes work
An integration is a credential with a job to do. Nothing about the design assumes a human holds it.
-
Scoped read and write
Access is granted per module, so an integration that books work does not need the billing module and does not get it.
-
Hashed and shown once
A key is displayed at the moment it is created and stored only as a hash. Losing one means issuing a new one, not recovering the old one.
-
Inherits its owner
A key carries exactly the permissions and companies of the account that created it, and cannot reach past them.
-
Revocable immediately
Disable a key and every request using it stops. Nothing else on the account is disturbed.
-
Optional expiry
A key can be issued with an expiry date for temporary or contractor access.
-
Every use is recorded
Actions are written to the audit trail against the account that owns the key, so a key is never anonymous.
Why the platform was built this way
Most business software treats its API as a concession. It exists, it lags the interface, and some things are simply not exposed. That is no longer a defensible position now that a meaningful share of work is done by software talking to software.
The rule here is the opposite. A capability is designed as an interface first and then wrapped in a screen. The screen is a client. The command line is a client. An agent is a client. If something is missing from one of them, it is a bug rather than a decision.
It also future proofs the work. When an operation is available over a documented interface with a machine readable specification, the next tool that needs it does not require anyone's permission or a new integration project. It reads the specification and does the work.
And it means the audit trail is complete. An agent, a script, a scheduled job and a person all arrive through the same door, so every change is attributable to something identifiable rather than to root.
What each plan includes
| Free and Starter | Growth | Scale and above | White label | |
|---|---|---|---|---|
| Console access | Yes | Yes | Yes | Yes |
| REST API | Not included | Yes | Yes | Yes |
| Published API specification | Not included | Yes | Yes | Yes |
| Command line | Not included | Yes | Yes | Yes |
| Agent protocol server | Not included | Yes | Yes | Yes |
| Scoped API keys | Not included | Yes | Yes | Yes |
| Webhooks | Not included | Not included | Yes | Yes |
| Your own API surface for your customers | Not included | Not included | Not included | Yes |
Questions people ask before signing up
Is there a sandbox?
Yes. A test company can be created alongside the real one with its own records and its own keys, so an integration can be built and broken without touching live data.
Are there rate limits?
Requests are rate limited per key to protect the platform, and the limit is generous enough that a normal integration never meets it. The response headers tell you where you are against the limit rather than leaving you to discover it by being refused.
What happens if an integration breaks something?
Everything it did is attributed to its key and visible in the audit trail, and the key can be disabled immediately. Financial records are voided rather than deleted and merges are reversible, so a bad batch can be walked back.
Can I use an agent client that is not yours?
Yes. The agent server speaks a standard protocol, so any compatible client can use it. There is nothing proprietary about the connection, and the key is the only thing that decides what the agent can reach.
Can I build my own product on top of this?
That is what white label is for. It gives you the platform under your own brand with resale rights, and the same interfaces to build against.
Start on the free plan
Twenty customers, one location, every core module, free permanently. Move up when the work outgrows it.