Schemas are the foundation of Enravo Core's Platform layer. Define your data model — the UnifiedDriver generates CRUD endpoints, the SchemaPipeline handles validation and permission filtering, and the Schema Registry auto-registers abilities. Two schema types: singletons (settings) and collections (entities).
Every data model is expressed as a declarative schema with typed fields, validation rules, UI rendering hints, and field-level access control. Each field defines who can read or write it per operation — create, update, or view — and supports secret field encryption out of the box.
1# Schema definition — CRUD auto-generated2id: customer3label: Customer4fields:5 - key: name6 type: string7 required: true8 searchable: true9 ui: { placeholder: "Full name" }10 access:11 readable: [admin, support, owner]12 writable: [admin, owner]13
14 - key: email15 type: email16 unique: true17 required: true18 access:19 readable: [admin, support, owner]20 writable: [admin]21
22 - key: api_secret23 type: string24 secret: true # API returns {hasValue: bool}25 access:26 readable: [admin]27 writable: [admin]28
29 - key: tier30 type: enum31 options: [free, starter, business, enterprise]32 default: free33 access:34 readable: [admin, support, owner]35 writable: [admin]36
37 - key: notes38 type: text39 ui: { rows: 4, placeholder: "Internal notes" }40 access:41 readable: [admin, support]42 writable: [admin, support]When a schema is registered, the platform reads its definition and generates everything needed to operate on that data — database storage, input validation, REST API routes, and fine-grained permission scopes. No controllers to write, no migrations to manage, no route files to maintain.
/enravo/v1/data/customer201{
"success": true,
"data": {
"id": 47,
"schema_id": "customer",
"fields": {
"name": "Acme Corp",
"email": "ops@acme.com",
"api_secret": "••••••••••••",
"tier": "business",
"notes": null
},
"meta": {
"created_at": "2025-11-02T14:22:00Z",
"created_by": "usr_3f9a"
}
}
}The building blocks that make schema-driven development practical at every layer of the stack.
A single storage abstraction that handles both option-based key-value pairs and dedicated custom tables — chosen per schema, transparent to the consumer.
Every write passes through a validation and transformation pipeline derived from the schema. Type coercion, constraint checks, and secret encryption happen before data reaches storage.
Frontend forms are generated directly from the schema definition — field types, placeholders, visibility rules, and access restrictions map to UI components automatically.
From definition to serving — every schema follows a deterministic registration pipeline that provisions the full stack.
Define Schema
Declare fields, types, validation, access control, and UI hints
Register
Schema engine reads and validates the definition at boot
Generate Storage
Database tables or option entries created from field definitions
Generate API
RESTful CRUD endpoints provisioned under /enravo/v1/data/{schema_id}
Generate Permissions
Read, write, and delete scopes registered for the schema
Serve
Schema is live — queryable, writable, and access-controlled
Define Schema
Declare fields, types, validation, access control, and UI hints
Register
Schema engine reads and validates the definition at boot
Generate Storage
Database tables or option entries created from field definitions
Generate API
RESTful CRUD endpoints provisioned under /enravo/v1/data/{schema_id}
Generate Permissions
Read, write, and delete scopes registered for the schema
Serve
Schema is live — queryable, writable, and access-controlled