Apiagex Readme

English: Apiagex is a fresh MVP headless CMS/API platform on one server. Hinglish: Apiagex ek fresh MVP headless CMS/API platform hai jo ek server par chalega.

Start Here

Use /adminui for React UI and /api for backend routes.
Owner login starts in /adminui and uses the bootstrap/login APIs.

Schemas

Schema APIs are now available at /api/admin/schemas for owner/admin workflows.
Schema APIs ab owner/admin workflow ke liye /api/admin/schemas par available hain.
The React Admin UI can create schemas from a form after owner login.
React Admin UI owner login ke baad form se schema create kar sakta hai.
Relation fields use an existing-schema picker before save.
Relation fields save se pehle existing-schema picker use karte hain.
Task3 relation contract defines one-to-one, one-to-many, many-to-one, and many-to-many relation types.
Task3 relation contract one-to-one, one-to-many, many-to-one, aur many-to-many relation types define karta hai.
One-to-one example: User Profile to User. Many-to-one example: Articles to Category.
One-to-one example: User Profile to User. Many-to-one example: Articles to Category.
One-to-many example: Author to Articles. Many-to-many example: Articles to Tags.
One-to-many example: Author to Articles. Many-to-many example: Articles to Tags.
Runtime relation validation, JSON storage, delete guards, schema metadata, and Admin UI relation controls are now ready.
Runtime relation validation, JSON storage, delete guards, schema metadata, aur Admin UI relation controls ab ready hain.
Admin UI relation setup: create the target schema first, then choose relation type and target schema in the source schema builder.
Admin UI relation setup: pehle target schema banao, phir source schema builder me relation type aur target schema choose karo.
Raw response example: GET /api/content/book/:entryId returns data.author as "AUTHOR_ENTRY_ID".
Raw response example: GET /api/content/book/:entryId data.author ko "AUTHOR_ENTRY_ID" return karta hai.
Populated response example: GET /api/content/book/:entryId?populate=relations returns data.author as an entry object with id, schemaId, data, createdAt, and updatedAt.
Populated response example: GET /api/content/book/:entryId?populate=relations data.author ko id, schemaId, data, createdAt, aur updatedAt wale entry object me return karta hai.
Read /doc for schema examples and relation validation rules.
/doc me schema examples aur relation validation rules padho.
Schema builder checkpoint v0.3.5 is ready.
Schema builder checkpoint v0.3.5 ready hai.

Entries And APIs

Entry repository validation is ready for admin and dynamic APIs.
Entry repository validation admin aur dynamic APIs ke liye ready hai.
Entry admin APIs are available below each schema.
Entry admin APIs har schema ke below available hain.
The React Admin UI can create entries from generated forms.
React Admin UI generated forms se entries create kar sakta hai.
Dynamic content APIs are ready under /api/content/:schemaSlug.
Dynamic content APIs /api/content/:schemaSlug ke under ready hain.
List filters: GET /api/content/:schemaSlug?fields=title&search=hello&limit=50&offset=0 supports selected fields, find, and pagination metadata.
List filters: GET /api/content/:schemaSlug?fields=title&search=hello&limit=50&offset=0 selected fields, find, aur pagination metadata support karta hai.
Single-entry projection: GET /api/content/:schemaSlug/:entryId?fields=title returns only the selected field in data.
Single-entry projection: GET /api/content/:schemaSlug/:entryId?fields=title data me sirf selected field return karta hai.
Admin Entries now shows an attached left Collections submenu and a table with find, visible field checkboxes, last 50 default rows, and pagination.
Admin Entries ab attached left Collections submenu aur table dikhata hai jisme find, visible field checkboxes, last 50 default rows, aur pagination hai.
Admin Entries create flow uses a compact Create entry button and opens the form only when needed.
Admin Entries create flow compact Create entry button use karta hai aur form sirf zarurat par open hota hai.
Create relation payload example: POST /api/content/book with { data: { title: "Kindred", author: "AUTHOR_ENTRY_ID" } }.
Create relation payload example: POST /api/content/book me { data: { title: "Kindred", author: "AUTHOR_ENTRY_ID" } } bhejo.
Multi relation payload example: POST /api/content/article with { data: { title: "Intro", tags: ["TAG_ONE_ID", "TAG_TWO_ID"] } }.
Multi relation payload example: POST /api/content/article me { data: { title: "Intro", tags: ["TAG_ONE_ID", "TAG_TWO_ID"] } } bhejo.
Use ?populate=relations, ?populate=all, or ?populate=* on dynamic read/list routes to expand one-level relation fields.
Dynamic read/list routes par one-level relation fields expand karne ke liye ?populate=relations, ?populate=all, ya ?populate=* use karo.
Admin UI entries: single relation fields use select controls, multi relation fields use multi-select controls, and required relation fields show ENTRY_FIELD_REQUIRED before save.
Admin UI entries: single relation fields select controls use karte hain, multi relation fields multi-select controls use karte hain, aur required relation fields save se pehle ENTRY_FIELD_REQUIRED dikhate hain.
Common relation errors: wrong value shape gives RELATION_VALUE_SHAPE_INVALID, missing target entry gives RELATION_TARGET_ENTRY_INVALID, reused one-to-one target gives RELATION_ONE_TO_ONE_CONFLICT, and deleting a referenced schema gives RELATION_SCHEMA_REFERENCED.
Common relation errors: wrong value shape par RELATION_VALUE_SHAPE_INVALID, missing target entry par RELATION_TARGET_ENTRY_INVALID, reused one-to-one target par RELATION_ONE_TO_ONE_CONFLICT, aur referenced schema delete par RELATION_SCHEMA_REFERENCED milta hai.
Admin UI now lists generated dynamic APIs.
Admin UI ab generated dynamic APIs list karta hai.
Read /doc and /readme for dynamic API examples.
Dynamic API examples ke liye /doc aur /readme padho.
Dynamic API checkpoint v0.4.6 is ready.
Dynamic API checkpoint v0.4.6 ready hai.

Roles And Users

Settings role control is split between /adminui#settings/admin-roles, /adminui#settings/content-roles, and /adminui#settings/webhooks.
Settings role control /adminui#settings/admin-roles, /adminui#settings/content-roles, aur /adminui#settings/webhooks me split hai.
Permission evaluator defaults to block, getAll allows list reads, get allows one-entry reads, realtime allows WebSocket subscribe, and manage allows all content API actions for API roles only.
Permission evaluator default block karta hai, getAll list reads allow karta hai, get one-entry reads allow karta hai, realtime WebSocket subscribe allow karta hai, aur manage sirf API roles ke liye all content API actions allow karta hai.
Content Roles manages API permissions, while Admin Roles manages admin panel roles and admin_permissions.
Content Roles API permissions manage karta hai, jabki Admin Roles admin panel roles aur admin_permissions manage karta hai.
Allowed API roles and valid API tokens succeed; blocked roles return API_PERMISSION_DENIED and revoked tokens return API_TOKEN_INVALID.
Allowed API roles aur valid API tokens succeed karte hain; blocked roles API_PERMISSION_DENIED aur revoked tokens API_TOKEN_INVALID return karte hain.
User admin APIs are ready for the Admin UI user screen.
User admin APIs Admin UI user screen ke liye ready hain.
User management UI is ready for the RBAC end-to-end flow.
User management UI RBAC end-to-end flow ke liye ready hai.
RBAC end-to-end verifies allowed and blocked user API access.
RBAC end-to-end allowed aur blocked user API access verify karta hai.
Read /doc and /readme for RBAC allow/block examples.
RBAC allow/block examples ke liye /doc aur /readme padho.
Blocked RBAC requests return API_PERMISSION_DENIED.
Blocked RBAC requests API_PERMISSION_DENIED return karte hain.

Workflow APIs

Workflow APIs created in Settings > Workflows are called at /api/custom/:path after activation.
Settings > Workflows me bani Workflow APIs activation ke baad /api/custom/:path par call hoti hain.
Public workflow call: allow the workflow route for the public role in Custom API Permissions, then call it without Authorization.
Public workflow call: Custom API Permissions me workflow route ko public role ke liye allow karo, phir bina Authorization call karo.
Token workflow call: allow the workflow route for a content API role, create an API token for that role, and send Authorization: Bearer API_TOKEN.
Token workflow call: workflow route ko content API role ke liye allow karo, us role ka API token banao, aur Authorization: Bearer API_TOKEN bhejo.
Blocked workflow calls return CUSTOM_API_PERMISSION_DENIED; inactive workflows are not mounted.
Blocked workflow calls CUSTOM_API_PERMISSION_DENIED return karte hain; inactive workflows mounted nahi hote.
Register starter: Settings > Workflows has Create register template for an inactive /api/custom/auth/register flow using a users content schema.
Register starter: Settings > Workflows me Create register template hai jo users content schema ke saath inactive /api/custom/auth/register flow banata hai.
Password warning: the register template validates password but does not store it; replace PASSWORD_HASH_PLACEHOLDER_REPLACE_WITH_SERVER_SIDE_HASHING with real hashing before production.
Password warning: register template password validate karta hai lekin store nahi karta; production se pehle PASSWORD_HASH_PLACEHOLDER_REPLACE_WITH_SERVER_SIDE_HASHING ko real hashing se replace karo.
OTP template plan: docs/otp-workflow-template-plan.md defines OTP request, OTP verify, expiry, retry limits, provider config, and token issuance needs before implementation.
OTP template plan: docs/otp-workflow-template-plan.md implementation se pehle OTP request, OTP verify, expiry, retry limits, provider config, aur token issuance needs define karta hai.
OTP safety: raw OTP codes must never be stored, logged, or returned; verify must consume a valid challenge before issuing any session/token.
OTP safety: raw OTP codes kabhi store, log, ya return nahi hone chahiye; verify ko session/token issue karne se pehle valid challenge consume karna hoga.
Google login plan: docs/google-login-workflow-template-plan.md defines server-side ID token verification, user lookup/create, allowed domains, and session/token handoff needs.
Google login plan: docs/google-login-workflow-template-plan.md server-side ID token verification, user lookup/create, allowed domains, aur session/token handoff needs define karta hai.
Google safety: never trust client-supplied profile fields or decode-only JWT payloads; verify signature, issuer, audience, expiry, subject, verified email, and optional hosted domain.
Google safety: client-supplied profile fields ya decode-only JWT payloads trust mat karo; signature, issuer, audience, expiry, subject, verified email, aur optional hosted domain verify karo.
Order status template: Settings > Workflows can create an inactive POST /api/custom/orders/status starter that validates orderId/status, updates the order entry, and blocks invalid transitions.
Order status template: Settings > Workflows inactive POST /api/custom/orders/status starter bana sakta hai jo orderId/status validate karta hai, order entry update karta hai, aur invalid transitions block karta hai.
Order status transitions: pending can move to preparing or cancelled, preparing can move to ready or cancelled, ready can move to completed, and invalid transitions return ORDER_STATUS_TRANSITION_INVALID.
Order status transitions: pending se preparing ya cancelled, preparing se ready ya cancelled, ready se completed allowed hai, aur invalid transitions ORDER_STATUS_TRANSITION_INVALID return karte hain.
Report template: Settings > Workflows can create an inactive read-only GET /api/custom/reports/orders starter that queries the orders schema with limit 50 and returns total plus entries.
Report template: Settings > Workflows inactive read-only GET /api/custom/reports/orders starter bana sakta hai jo orders schema ko limit 50 ke saath query karta hai aur total plus entries return karta hai.
Report limits: keep MVP report templates bounded; large reports must respect workflow runtime query limits.
Report limits: MVP report templates bounded rakho; large reports ko workflow runtime query limits respect karna hoga.
Graph editor plan: docs/workflow-graph-editor-plan.md chooses React Flow and keeps the visual graph as a projection of validated workflow JSON.
Graph editor plan: docs/workflow-graph-editor-plan.md React Flow choose karta hai aur visual graph ko validated workflow JSON ka projection rakhta hai.
Secret store plan: docs/workflow-secret-store-plan.md requires workflow JSON to store only secret references such as secret:stripe.secretKey.
Secret store plan: docs/workflow-secret-store-plan.md workflow JSON me sirf secret:stripe.secretKey jaise references allow karta hai.
Secret values must live in env-backed or encrypted secret storage and must be redacted from workflow history, tests, webhooks, realtime events, and logs.
Secret values env-backed ya encrypted secret storage me rahenge aur workflow history, tests, webhooks, realtime events, aur logs se redact honge.
HTTP node plan: docs/workflow-http-request-node-plan.md requires method, URL allowlist, SSRF guard, headers, body templates, timeout, retry, and secret references.
HTTP node plan: docs/workflow-http-request-node-plan.md method, URL allowlist, SSRF guard, headers, body templates, timeout, retry, aur secret references require karta hai.
Implemented HTTP request nodes use APIAGEX_WORKFLOW_HTTP_ALLOWED_HOSTS for host allowlisting and env-backed secret references like APIAGEX_SECRET_PROVIDER_APIKEY.
Implemented HTTP request nodes host allowlisting ke liye APIAGEX_WORKFLOW_HTTP_ALLOWED_HOSTS aur env-backed secrets jaise APIAGEX_SECRET_PROVIDER_APIKEY use karte hain.
Password node plan: docs/workflow-password-node-plan.md requires Argon2id or reviewed fallback hashing, per-password salts, safe verify, redaction, and migration guidance.
Password node plan: docs/workflow-password-node-plan.md Argon2id ya reviewed fallback hashing, per-password salts, safe verify, redaction, aur migration guidance require karta hai.
Implemented password nodes use Node crypto.scrypt with per-password salts and timing-safe verify; plain passwords are not returned in node output.
Implemented password nodes Node crypto.scrypt, per-password salts, aur timing-safe verify use karte hain; plain passwords node output me return nahi hote.
Issue-token plan: docs/workflow-issue-token-node-plan.md keeps app-user tokens separate from Admin owner sessions and binds them to Content/API roles.
Issue-token plan: docs/workflow-issue-token-node-plan.md app-user tokens ko Admin owner sessions se alag rakhta hai aur Content/API roles se bind karta hai.
Practical guide: docs/workflow-builder-practical-guide.md shows schema creation, workflow steps, test run, permission allow, token creation, and curl calls.
Practical guide: docs/workflow-builder-practical-guide.md schema creation, workflow steps, test run, permission allow, token creation, aur curl calls dikhata hai.
Release checkpoint: docs/workflow-builder-release-checkpoint.md is the first Workflow Builder milestone gate before publish.
Release checkpoint: docs/workflow-builder-release-checkpoint.md publish se pehle first Workflow Builder milestone gate hai.

Verification

Admin UI redesign uses a custom shell, light/dark mode, responsive lists, accessible keyboard navigation, confirm dialogs, and status toasts.
Admin UI redesign custom shell, light/dark mode, responsive lists, accessible keyboard navigation, confirm dialogs, aur status toasts use karta hai.
/adminui remains the React Admin UI route; /doc and /readme remain public docs routes served by the same API server.
/adminui React Admin UI route hi hai; /doc aur /readme same API server se served public docs routes hi hain.
Admin UI workflows cover owner login, schema builder, entries, generated APIs, relation modeling, RBAC roles, users, and settings.
Admin UI workflows owner login, schema builder, entries, generated APIs, relation modeling, RBAC roles, users, aur settings cover karte hain.
npm run smoke verifies the MVP owner/schema/entry/dynamic API/RBAC flow.
npm run smoke MVP owner/schema/entry/dynamic API/RBAC flow verify karta hai.