Your stack.
Your way to build.
Use APIs, official packages, and a Next.js storefront starter to connect Ominity to the experience you want to create.
GET /api/v1/cms/pages
Instance → Content pages
title: A summer worth sharingUse your instance reference for the full schema.
GET /api/v1/commerce/products
Instance → Catalog products
name: The everyday vesselUse your instance reference for the full schema.
A useful boundary.
A practical path into the code.
Choose the interface, the packages, and the domain capabilities your application needs. Keep credentials, context, and business actions explicit from the first request.
One backend foundation.
The interfaces you choose.
Use the API to connect content and commerce to a storefront, portal, or application. Your frontend owns presentation; shared records and supported business operations remain in the Ominity instance.
- Request pages and products under /api/v1
- Keep privileged integration keys on the server
- Carry the correct customer context into scoped work
Use the package
that fits the project.
Start with official TypeScript or PHP SDKs, framework packages for Next.js and Laravel, or the available Next.js storefront starter. Read the source and configuration for the version your project installs.
- Choose a language or framework package
- Inspect the official repository documentation
- Use the storefront source as an adaptable beginning
npm add @ominity/api-typescriptcomposer require ominity/ominity-api-phpnpm add @ominity/nextcomposer require ominity/laravel-ominityMake the data contract
deliberate.
Custom content types model domain information. Custom fields extend existing records with typed values and configurable response, update, and filtering behavior, so the frontend has a clearer contract to build against.
- Choose meaningful field types and relationships
- Control whether a field appears in API responses
- Configure update and filtering behavior
Give the AI tool
the context of the project.
Connect a compatible tool through MCP to supported content and blueprint capabilities. Use that context alongside SDK and frontend work, then inspect the generated structure and integration before using it.
- Create or update supported content structures
- Connect the instance your tool should work with
- Review the output and permissions deliberately
Debug the operation.
Follow its actual outcome.
The execution pipeline connects an action to permissions, rules, record changes, and outbox work. Follow rejection reasons and delivery attempts in context instead of inferring the business outcome from a single request.
- Inspect the actor and request context
- Distinguish rejection from delivery failure
- Reason about repeats with idempotency
execution / example-042- 01RequestUpdate a product
Actor and customer context
- 02DecisionAllowed to proceed
Permissions and rules evaluated
- 03ChangeProduct updated
Recorded outcome
- 04OutboxExternal work queued
Delivery has a separate state
Inspect the action through its outcome.
Explore the details.
The capabilities, examples, and integration choices behind this solution.
One complete interaction.
A better place to start.
Connect a page or a business operation end to end, then expand the integration around what you learn.