Build your first Niqat App
Plan your first Niqat App: choose a customization pack, workflow, or service integration, define permissions and retries, and prepare for future Store distribution.
A Niqat App should help a business do something concrete: connect a service, prepare useful customization, or coordinate a workflow. Begin with the job, then choose the narrowest supported boundary.
Choose the right surface
| Need | Starting point |
|---|---|
| A reusable appearance or setup | A validated customization pack |
| An action following a business event | A versioned workflow trigger and allowed command |
| A connected external service | A service integration with explicit authorization and retry behavior |
The Niqat Store and its app distribution experience are coming soon. This guide describes the integration approach; it does not promise an installable public SDK or a universal app manifest.
Write the integration contract
Describe the event or user action, the exact data required, the company scope, the authorized operation, and the expected result. Define what happens if the request is retried, the connection fails, or the user loses permission.
Use stable identifiers. Do not identify a customer or document only by mutable display text. Preserve exact currency and quantity semantics.
Keep authority explicit
An integration must not bypass a staff member’s permissions or write directly into operational tables. A configuration file is data, not executable authority. Keep credentials on the appropriate server boundary and out of shared packs and browser bundles.
Prepare for distribution
Keep source, version, compatibility requirements, and the user-facing explanation together. State what the app reads, what it changes, and how a user can review the result.
Next, read shareable packs and workflow integrations. Use the release-specific endpoint and authentication documentation when an integration surface publishes it; do not guess API routes from internal source paths.
Continue readingArchitecture overview