Screens and data
OpenAPI describes API operations and JSON Schema describes data. Portable views combine forms, tables, details and commands into pages, with optional JSON Forms layouts and no required frontend framework.
A specification for portable admin modules
Many services.
One admin
language.
We’re developing a common way to connect services and microservices to one admin interface, with shared rules for access, tenants and audit records.
Explore the ideaSpecification in development · Draft 0.1.0
FIG. 01A COMMON CONTRACT
WHAT WE’RE BUILDING
One workspace for the services behind your product
OpenAdminSpec is a draft specification for connecting independent services to a shared admin interface. A service describes what can be managed and how; an admin platform uses that description to present screens, check access and call its API.
As a product grows, billing, user accounts and content often end up in separate tools. Teams rebuild forms, tables and integrations for each service. A common contract aims to make that work reusable while each service keeps its own API and business rules.
HOW IT FITS TOGETHER
Describe, connect, manage
-
Describe the service
The service team publishes a module: a description of its API actions, screens, data and access requirements. It contains the administration contract, while the service implements the actual operations.
-
Approve a connection
An operator reviews the module and connects a specific service instance to the platform. They approve its address, credentials, version and access rules, including project mappings where needed.
-
Work through its API
A compatible platform builds the declared interface. When someone runs an action, it checks permissions, supplies the approved context and calls the service, which enforces its own rules.
THE CONTRACT
What the specification brings together
Authentication and permissions
API authentication and the right to perform an action are separate from a person’s login to the panel. Both the platform and service must check access; credentials stay outside the module description.
Tenants and service connections
Independent connections can reuse one module. Optional tenants are customers or projects with their own data and access rules. The platform selects their context, and services must enforce the data boundaries.
Actions, jobs and files
Describe immediate actions, background jobs with progress and results, and controlled file uploads and downloads. These operations use the same permissions and selected service or project context.
Versions and approval
Validation checks the description. The platform must support its required capabilities before a connection or update is approved. Approved versions remain unchanged; changing a connection’s selected version requires approval.
A common audit format
Record who initiated an action, which connection or project it concerned, and any confirmed result. Shared event fields help a platform follow the request and distinguish completion, failure and uncertain outcomes.
FOR EXAMPLE
One product, several services
Imagine a subscription product with billing, accounts and content services. Support could find a customer’s account, finance review invoices, and an editor update that customer’s content in one workspace. Each action would retain its service, customer context and permission checks.
Service teams could maintain their module descriptions while the platform team builds shared administration tools. Changes would pass through version review instead of silently altering live connections. This is the direction of draft 0.1.0; implementations are being developed separately.
WORK IN PROGRESS
A common language is taking shape
The specification is an evolving draft. The full site is coming soon.