Jomioz Data Model: Resources, Events, and User Objects

Jomioz represents your domain through three first-class object types — Resources, Events, and Users — each with a well-defined schema and clear relationships to the others. Understanding these schemas helps you design integrations that read and write data efficiently, construct precise API filters, and interpret the payloads your webhooks and event streams deliver.

Resources

A resource is the primary data object you create and manage in Jomioz. Resources are generic by design: the type field lets you classify them for your domain, while the metadata field holds any additional key-value data your application needs.

Resource fields

Field	Type	Description
`id`	string	Unique identifier for the resource, prefixed with `res_`.
`name`	string	Human-readable display name you assign when creating the resource.
`type`	string	A free-form string that categorizes the resource within your workspace (e.g. `"order"`, `"customer"`, `"device"`).
`status`	string	Lifecycle state of the resource. One of `active`, `inactive`, or `archived`.
`metadata`	object	Free-form key-value pairs you attach to the resource. Keys and values are strings.
`created_at`	string	ISO 8601 timestamp recording when the resource was created.
`updated_at`	string	ISO 8601 timestamp recording when the resource was last modified.

Resource object schema

string

required

Unique identifier for the resource. Always prefixed with res_.Example: "res_01hxyz4kab3cdef56789"

string

required

Human-readable display name assigned at creation time. Must be between 1 and 255 characters.

string

required

A free-form string categorizing the resource within your workspace. Use consistent, slug-style values (e.g. "order", "customer") to make filtering and querying predictable.

string

required

Current lifecycle state of the resource.Allowed values: active, inactive, archived

object

A flat object of string key-value pairs you control. Jomioz does not interpret these values — they are stored and returned as-is. See the Metadata section for usage guidance.

Show metadata properties

string

Any string key you define. Both keys and values must be strings. An object may contain up to 50 key-value pairs; individual values may not exceed 500 characters.

string

required

ISO 8601 timestamp (UTC) recording when the resource was created.Example: "2024-06-15T09:42:11Z"

string

required

ISO 8601 timestamp (UTC) recording when the resource was last modified. Equals created_at for resources that have never been updated.Example: "2024-06-17T14:05:33Z"

Example resource object

{
  "id": "res_01hxyz4kab3cdef56789",
  "name": "Acme Corporation Account",
  "type": "customer",
  "status": "active",
  "metadata": {
    "plan": "enterprise",
    "region": "us-east-1",
    "account_manager": "jane.doe@yourcompany.com"
  },
  "created_at": "2024-06-15T09:42:11Z",
  "updated_at": "2024-06-17T14:05:33Z"
}

Events

Every state change on a resource — creation, update, deletion, or an integration-triggered sync — appends an immutable event record. Events form a chronological log you can query, replay, and stream in real time.

Event fields

Field	Type	Description
`id`	string	Unique identifier for the event, prefixed with `evt_`.
`resource_id`	string	The `id` of the resource this event belongs to.
`type`	string	The kind of change that occurred (e.g. `resource.created`, `resource.updated`, `resource.deleted`).
`payload`	object	A snapshot of relevant data at the time of the event. Shape varies by event type.
`timestamp`	string	ISO 8601 timestamp (UTC) recording when the event was emitted.

Example event object

{
  "id": "evt_09azqr8mnp1bcde23456",
  "resource_id": "res_01hxyz4kab3cdef56789",
  "type": "resource.updated",
  "payload": {
    "previous": {
      "status": "inactive"
    },
    "current": {
      "status": "active"
    },
    "changed_fields": ["status"]
  },
  "timestamp": "2024-06-17T14:05:33Z"
}

The payload shape is specific to each event type. resource.created payloads include the full resource object; resource.updated payloads include previous, current, and changed_fields; resource.deleted payloads include the final state of the resource before deletion. Consult the Events API reference for per-type payload schemas.

Users

Users represent the human members of your workspace. Every user belongs to exactly one workspace account and is assigned a role that governs what they can read and modify. User objects are managed at the workspace level — you invite, update, and remove users through the workspace membership API or the dashboard’s Team panel.

User fields

Field	Type	Description
`id`	string	Unique identifier for the user, prefixed with `usr_`.
`email`	string	The email address the user authenticates with. Must be unique within the workspace.
`role`	string	The user’s permission level. One of `owner`, `admin`, or `member`.
`created_at`	string	ISO 8601 timestamp recording when the user joined the workspace.

Example user object

{
  "id": "usr_07bpqw2stu5vwxy89012",
  "email": "alex.smith@yourcompany.com",
  "role": "admin",
  "created_at": "2024-05-01T08:00:00Z"
}

User objects do not carry API keys. API keys are workspace-scoped credentials that exist independently of any individual user. This means you can revoke a team member’s access without invalidating the API keys your services rely on.

Metadata

The metadata field on every resource is a flat, free-form object of string key-value pairs that you fully control. Jomioz stores and returns these values verbatim — they are never interpreted, indexed for full-text search, or used to drive platform behaviour. Use metadata to attach application-specific context directly to a resource so you do not need a separate lookup in your own database:

{
  "metadata": {
    "external_id": "acme-corp-001",
    "tier": "enterprise",
    "onboarded_by": "sales-team-emea",
    "contract_expires": "2025-12-31"
  }
}

You can filter resources by metadata values through the API using the metadata[key]=value query parameter syntax:

curl "https://api.jomioz.com/v1/resources?metadata[tier]=enterprise" \
  -H "Authorization: Bearer YOUR_API_KEY"

Metadata values are not encrypted at rest beyond Jomioz’s standard storage encryption. Do not store sensitive data — such as passwords, payment card numbers, or government-issued identifiers — in the metadata field.

Keep the following limits in mind when designing your metadata schema:

Maximum 50 key-value pairs per resource.
Keys may be up to 64 characters; values may be up to 500 characters.
All keys and values must be strings — numbers, booleans, and nested objects are not supported.

Get Started

Core Concepts

Guides

Integrations

Support

Jomioz Data Model: Resources, Events, and User Objects

Resources

Resource fields

Resource object schema

Example resource object

Events

Event fields

Example event object

Users

User fields

Example user object

Metadata

​Resources

​Resource fields

​Resource object schema

​Example resource object

​Events

​Event fields

​Example event object

​Users

​User fields

​Example user object

​Metadata

Resources

Resource fields

Resource object schema

Example resource object

Events

Event fields

Example event object

Users

User fields

Example user object

Metadata