Frontends get predictable resources
Consistent collection, record, and relationship routes remove one-off endpoint conventions.
Daptin
Run Daptin →
APIs and discovery
Serve the same application data through JSON:API and optional GraphQL. Let people browse it, let tools discover it, and keep the access model consistent across both.
Ready to query
Clients can filter, sort, paginate, aggregate, follow relationships, and request individual resources. Daptin applies its data and permission model before results reach the client.
Consistent collection, record, and relationship routes remove one-off endpoint conventions.
Enable GraphQL when a client needs to select connected fields in one query.
OpenAPI, metadata routes, and generated JavaScript models make the running application inspectable.
Ordinary values are parameterized, while supported sorting and aggregation inputs are validated before SQL is built.
Built for real clients
Use predictable resource URLs, sparse client requests, pagination, related records, and JWT authentication from ordinary HTTP libraries.
Filter, sort, group, and aggregate without creating a bespoke reporting handler for each list or dashboard.
Enable GraphQL where one screen benefits from selecting fields across connected records while other clients keep JSON:API.
Use OpenAPI, runtime metadata, and generated JavaScript models to inspect the server instead of maintaining a separate description by hand.
Limits
The same resource and relationship permissions apply when clients query the generated interfaces. Ordinary values are passed as parameters and supported sort or aggregation inputs are validated before query construction.
The latest release does not impose a hard maximum on general REST
page[size]. Apply an API-gateway policy for public
traffic, use stable pagination order, and test expensive includes
and aggregates. GraphQL is optional, and discovery describes the
model currently loaded by the running server.