Resources
The core building block of every Snaapi API.
A resource is the central building block of any Snaapi API. Conceptually a resource is a named collection of records, comparable to a table in a relational database or a model in an ORM. Each resource has a defined shape (its fields), a set of permissions, and a generated REST surface.
What you get when you define a resource
Defining a resource gives you these things automatically.
- A REST endpoint at
/v1/<resource>with paginated list, retrieve, create, update, and delete operations. - Validation against the field definitions on every write.
- Role-based permissions on every read and write.
- A documented entry in your API's generated OpenAPI specification.
- Real-time change events over Server-Sent Events.
- An entry in the audit log for every mutation.
Creating your first resource
The fastest way to create a resource is through the API builder.
- Open the API builder and select Add Resource.
- Enter a name for your resource (for example,
posts). Names must start with a letter or underscore, contain only alphanumeric characters and underscores, and be at most 100 characters long. - Add one or more fields. For each field, choose a name and type, then
configure any properties like
requiredorunique. See Fields for the full list of types and options. - Optionally add a description and configure permissions.
- Select Save. Snaapi immediately generates REST API endpoints for your new resource. No deployment or restart is needed.
System fields
Every resource automatically includes three system-managed fields that you do not need to declare.
| Field | Type | Description |
|---|---|---|
id |
uuid |
Unique identifier, generated automatically |
created_at |
datetime |
Timestamp set when the record is created |
updated_at |
datetime |
Timestamp updated on every modification |
System fields are always returned in API responses and can be referenced in
permissions, filters, and sort operations. You cannot create custom fields with
these reserved names. When enableSoftDelete is true, deleted_at is also
reserved (see Soft delete below).
Soft delete
When Soft delete is enabled on a resource, deleting a record does not remove
it from the database. Instead, a deleted_at timestamp is set on the row. Soft
deleted records are excluded from normal queries but can be recovered or audited
later. The toggle lives on the resource's settings and is off by default.
Enabling and disabling resources
Each resource has an Enabled flag (on by default). Disabling a resource takes its API endpoints offline without deleting the resource definition or its data, which is useful for maintenance windows, staged rollouts, or deprecating endpoints while preserving the underlying data.
Relations
Resources can reference each other through relation fields, which store the
id of a record in another resource. A relation field is enough to traverse the
link in both directions from the generated API.
Where to go next
- Fields explains the field types and validation options.
- Permissions covers how to expose a resource to a role.