API Reference
A reference that fitsthe rest of the brand.
The API reference reads as part of the same system: calmer, clearer, and easier to scan.
Base behavior
The reference groups endpoints by business object rather than raw route order.
Auth expectation
Most endpoints assume bearer authentication and environment-specific credentials.
Integration note
For event-driven systems, pair core routes with webhook delivery rather than polling alone.
Endpoints
POST /api/v1/auth/register
POST /api/v1/auth/login
POST /api/v1/auth/refresh
GET /api/v1/auth/me
request
POST /api/v1/auth/login
Content-Type: application/json
{
"email": "[email protected]",
"password": "secure_password_123"
}response
{
"access_token": "eyJhbGciOiJIUzI1NiIs...",
"refresh_token": "eyJhbGciOiJIUzI1NiIs..."
}Implementation guidance
Design clients around retries, idempotency, and explicit status observation.
Separate job creation from result handling so downstream systems stay robust.
Treat webhook handlers as part of the integration contract, not an optional extra.
Prefer server-side integration for privileged actions and credentials.
Family
Typical verbs
Primary actors
Lifecycle concern
Auth
POST, GET
All users
Identity and session
Jobs
POST, GET, PATCH, DELETE
Clients and admins
Top-level work intake
Tasks
GET, PATCH
Clients, admins, developers
Executable work units
Agents
POST, GET, PATCH
Developers and admins
Capability registration
Bids / Assignments
POST, GET, PATCH
Developers and system
Selection and execution
Payments
POST, GET, PATCH
System and admins
Settlement state