Skip to main content
Jomioz is built around a small set of composable primitives — workspaces, resources, events, and integrations — that you combine to model your data, automate workflows, and connect third-party services. Once you understand how these objects relate to one another, every API call, dashboard action, and webhook payload will make immediate sense.

​
Platform Building Blocks

Workspaces

A workspace is your top-level container. All resources, events, team members, and API keys belong to a single workspace. Use separate workspaces to isolate projects, clients, or business units.

Resources

Resources are the core data objects you create and manage inside Jomioz. Each resource has a type, a status, and a free-form metadata bag that you can shape to fit your domain.

Events

Every meaningful state change on a resource emits an event. Events form an immutable, ordered log that you can query, replay, and stream in real time to your own systems.

Integrations

Integrations connect Jomioz to third-party platforms. Once connected, Jomioz can sync resources from external sources and emit events when those external objects change.

​
How Objects Relate

Jomioz follows a strict three-level hierarchy that determines ownership, access control, and event routing. Workspace → Resources → Events
  • A workspace owns everything inside it. API keys are scoped to a workspace, and team members are granted roles at the workspace level.
  • Resources live inside a workspace. Every resource belongs to exactly one workspace and carries a type that categorizes it within your domain model.
  • Events are always associated with a parent resource. When you create, update, or delete a resource — or when a connected integration reports a change — Jomioz appends an event to that resource’s event log.
This hierarchy means you can retrieve all events for a specific resource, all resources of a given type inside a workspace, or a full cross-resource event stream scoped to your workspace, depending on what your workflow requires.
Object relationship diagram — picture a tree rooted at your workspace. Each branch is a resource, and each leaf is an event on that resource. API keys and team members attach at the root, so a single set of credentials can act on any resource in the workspace. Integrations attach at the workspace level too, but they inject new resources and events automatically as external data changes.

​
Environments

Every workspace operates in one of two environments: production or sandbox. Production is your live environment. API keys prefixed with live_ authenticate against production data, rate limits are enforced at your plan tier (1,000 req/min on Standard, 5,000 req/min on Enterprise), and webhooks fire to your registered endpoints. Sandbox is an isolated replica of your workspace where no real-world side effects occur. API keys prefixed with test_ point to sandbox data. Use the sandbox to develop integrations, test webhook handlers, and rehearse destructive operations without affecting live resources.
Sandbox and production share the same API surface, so code you test against test_ keys will work unchanged when you switch to live_ keys in production.
You can toggle between environments from the Settings → Environments panel in the dashboard, or by simply swapping the API key prefix in your requests.