Skip to content

API

Minyu provides programmatic access to the system through a single, automatically generated GraphQL API. The API mirrors the configured data model exactly—tables, columns, relations, classifications, and rules—without custom resolvers, handwritten endpoints, or duplicated logic.

The API is not a secondary integration surface. It is a first-class interface to the system, evaluated under the same rules, permissions, and constraints as interactive usage.

Why GraphQL was chosen

GraphQL was selected as an architectural consequence of Minyu’s design, not as a frontend convenience.

Minyu is built around a rich, evolving relational model where relationships are as important as fields. Clients need to:

  • traverse relations deeply and selectively
  • fetch exactly the structure they need
  • adapt alongside an evolving model

GraphQL maps directly to these requirements.

Because the API schema is derived directly from the data model, there is no endpoint versioning, no resource-specific controllers, and no parallel API definitions to maintain. When the model changes, the API changes with it — immediately and transparently.

GraphQL enables:

  • a schema-derived API surface
  • explicit, typed relations instead of implicit joins
  • predictable evolution aligned with the domain model

Rather than freezing contracts through versioning, Minyu favors intentional, synchronized change: the API always reflects the current model, with the same structure, naming, rules, and access constraints as the rest of the system. This avoids drift between data, behavior, and integration logic, at the cost of requiring clients to evolve together with the model.

That trade-off is deliberate and consistent with Minyu’s model-driven design philosophy.

One schema, generated from the model

The GraphQL schema is generated directly from the configured API names on tables, columns, and relations.

For a table with API name person, the API exposes:

  • persons — query a collection
  • person — query a single row
  • add_person, edit_person, delete_person — mutations

Field names and relation names are taken directly from the model. There is no mapping layer that could drift or become incomplete.

Because the schema is generated automatically:

  • every table is queryable
  • every relation is traversable
  • every mutation follows the same structure

Schema changes take effect immediately after configuration changes.

Queries: model-aware data access

Queries provide read-only access to schema-defined data.

They support:

  • single-row and multi-row queries
  • unrestricted relation traversal
  • classification-based filtering
  • nested selection of related data

All queries are evaluated against live data.

Crucially, read rules are enforced on every query. Rows that are not visible to the authenticated user never appear in query results, regardless of traversal depth or selection shape.

There is no “raw data” mode and no way to bypass access logic through the API.

Mutations: transactional, rule-enforced changes

Mutations provide write access to schema-defined data.

Each mutation executes as a single transaction and supports both scalar field updates and relational edits. Write rules and classifications are evaluated during execution, and violations are returned as structured errors.

API access runs in user context

Every API request is executed in the context of an authenticated user.

There is no system-level API credential with implicit privileges. Integrations act as users, with roles, rules, and access boundaries defined exactly the same way as for interactive access.

In production environments, organizations typically create dedicated API users to isolate integration behavior from human accounts. This makes permissions explicit, auditable, and changeable without rotating credentials.

API authentication via delegated trust

Minyu delegates authentication to Firebase while retaining full control over authorization and access rules.

API access is performed using short-lived Firebase access tokens that are issued after an initial, one-time trust setup in Minyu. Minyu validates each token and executes requests in the context of the corresponding user or integration account.

No passwords or long-lived API keys are stored or issued by Minyu.

This model provides:

  • short-lived credentials that limit exposure if a token leaks
  • immediate effect of permission or role changes
  • centralized access control through user management
  • full attribution of all API activity to a user context

Token renewal and credential handling are fully delegated to Firebase and the integrating system, keeping Minyu focused on authorization, rules, and data governance.

Why this matters

APIs often become unintended escape hatches. Over time, business rules are enforced in one place but bypassed in another.

Minyu avoids this by making the API a direct expression of the system, not a translation layer around it.

The GraphQL API is:

  • model-derived
  • rule-aware
  • permission-safe
  • evolution-friendly

Integrations remain aligned with the data model and business logic even as the system evolves.

In Minyu, the API is not an add-on. It is the system—programmatically accessible.

→ Read more: API