Skip to content

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.

  1. Open the API builder and select Add Resource.
  2. 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.
  3. Add one or more fields. For each field, choose a name and type, then configure any properties like required or unique. See Fields for the full list of types and options.
  4. Optionally add a description and configure permissions.
  5. 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.