Apiagex Docs

English: Completed MVP base paths are /api, /api/health, /doc, /readme, and /adminui. Hinglish: Completed MVP base paths /api, /api/health, /doc, /readme, aur /adminui hain.

Owner Auth

Owner auth: POST /api/auth/bootstrap-owner creates the first owner, then POST /api/auth/login logs in.
Owner auth: POST /api/auth/bootstrap-owner pehla owner banata hai, phir POST /api/auth/login login karta hai.

Database Providers

Runtime database providers: SQLite is the default, PostgreSQL uses APIAGEX_DATABASE_PROVIDER=postgres plus APIAGEX_DATABASE_URL, and MySQL uses APIAGEX_DATABASE_PROVIDER=mysql plus APIAGEX_DATABASE_URL.
Runtime database providers: SQLite default hai, PostgreSQL ke liye APIAGEX_DATABASE_PROVIDER=postgres plus APIAGEX_DATABASE_URL use hota hai, aur MySQL ke liye APIAGEX_DATABASE_PROVIDER=mysql plus APIAGEX_DATABASE_URL use hota hai.
Create setup: npm create apiagex@latest asks for sqlite/postgres/mysql and writes .env, .env.example, apiagex.config.json, and src/index.js for the selected provider.
Create setup: npm create apiagex@latest sqlite/postgres/mysql puchta hai aur selected provider ke hisab se .env, .env.example, apiagex.config.json, aur src/index.js likhta hai.
Troubleshooting: DATABASE_URL_REQUIRED means a server database was selected without APIAGEX_DATABASE_URL; ECONNREFUSED means the database host is not reachable.
Troubleshooting: DATABASE_URL_REQUIRED ka matlab server database choose hua lekin APIAGEX_DATABASE_URL missing hai; ECONNREFUSED ka matlab database host reachable nahi hai.
Detailed provider docs: docs/database-provider-setup.md covers env examples, owner bootstrap, common errors, and optional PostgreSQL/MySQL integration test commands.
Detailed provider docs: docs/database-provider-setup.md env examples, owner bootstrap, common errors, aur optional PostgreSQL/MySQL integration test commands cover karta hai.

Schemas And Relations

Schemas: /api/admin/schemas supports create, list, read, update, and delete with field validation.
Schemas: /api/admin/schemas field validation ke saath create, list, read, update, aur delete support karta hai.
Admin UI: owner login reveals a React schema builder form for all MVP field types.
Admin UI: owner login ke baad React schema builder form sab MVP field types ke liye dikhata hai.
Relations: relation fields must pick an existing schema and are validated by the API.
Relations: relation fields existing schema pick karte hain aur API validate karti hai.
Task3 relation contract: one-to-one means one entry connects to one target entry, like User Profile to User.
Task3 relation contract: one-to-one ka matlab one entry ek target entry se connect hoti hai, jaise User Profile to User.
Task3 relation contract: many-to-one means many entries can point to one parent, like Articles to Category.
Task3 relation contract: many-to-one ka matlab many entries ek parent ko point kar sakti hain, jaise Articles to Category.
Task3 relation contract: one-to-many means one parent stores many child entry ids, like Author to Articles.
Task3 relation contract: one-to-many ka matlab one parent many child entry ids store karta hai, jaise Author to Articles.
Task3 relation contract: many-to-many means both sides can connect to many entries, like Articles and Tags.
Task3 relation contract: many-to-many ka matlab dono sides many entries se connect ho sakti hain, jaise Articles aur Tags.
Relation value shapes: one-to-one and many-to-one store one entry id string; one-to-many and many-to-many store arrays of entry ids.
Relation value shapes: one-to-one aur many-to-one ek entry id string store karte hain; one-to-many aur many-to-many entry id arrays store karte hain.
Relation payload example: POST /api/content/book can send { data: { title: "Kindred", author: "AUTHOR_ENTRY_ID", tags: ["TAG_ENTRY_ID"] } }.
Relation payload example: POST /api/content/book me { data: { title: "Kindred", author: "AUTHOR_ENTRY_ID", tags: ["TAG_ENTRY_ID"] } } bhejo.
Relation validation errors include RELATION_VALUE_SHAPE_INVALID:author, RELATION_TARGET_ENTRY_INVALID:author, RELATION_ONE_TO_ONE_CONFLICT:author, RELATION_SCHEMA_REFERENCED:target, and ENTRY_FIELD_REQUIRED:author.
Relation validation errors me RELATION_VALUE_SHAPE_INVALID:author, RELATION_TARGET_ENTRY_INVALID:author, RELATION_ONE_TO_ONE_CONFLICT:author, RELATION_SCHEMA_REFERENCED:target, aur ENTRY_FIELD_REQUIRED:author aate hain.
Current status: Task3 has relation contract, validation, JSON storage, delete safety, schema metadata, populate, Admin UI relation builders, entry pickers, and entry-list summaries.
Current status: Task3 me relation contract, validation, JSON storage, delete safety, schema metadata, populate, Admin UI relation builder, entry picker, aur entry-list summary ready hain.
Admin UI relation flow: create the target schema first, create source relation fields with relation type and target, then create entries with single or multi relation pickers.
Admin UI relation flow: pehle target schema banao, phir source schema me relation type aur target set karo, uske baad single ya multi relation picker se entries banao.
Docs: schema builder usage and relation rules are documented in English and Hinglish.
Docs: schema builder usage aur relation rules English aur Hinglish me documented hain.

Entries And Dynamic APIs

Entries: repository validation checks required fields, value types, unknown fields, and relation targets.
Entries: repository validation required fields, value types, unknown fields, aur relation targets check karta hai.
Entry APIs: /api/admin/schemas/:schemaId/entries supports admin CRUD per schema.
Entry APIs: /api/admin/schemas/:schemaId/entries per schema admin CRUD support karta hai.
Admin UI: Entry Manager renders entry forms from selected schema fields, including single relation selects and multi relation pickers.
Admin UI: Entry Manager selected schema fields se entry forms render karta hai, including single relation select aur multi relation picker.
Dynamic APIs: /api/content/:schemaSlug exposes schema-based CRUD.
Dynamic APIs: /api/content/:schemaSlug schema-based CRUD expose karta hai.
Raw relation response: GET /api/content/book/:entryId returns data.author as "AUTHOR_ENTRY_ID" unless populate is requested.
Raw relation response: GET /api/content/book/:entryId data.author ko "AUTHOR_ENTRY_ID" ke roop me return karta hai jab tak populate request nahi hota.
Populated relation response: GET /api/content/book/:entryId?populate=relations returns data.author as the related entry object with id, schemaId, data, createdAt, and updatedAt.
Populated relation response: GET /api/content/book/:entryId?populate=relations data.author ko related entry object ke roop me return karta hai jisme id, schemaId, data, createdAt, aur updatedAt hote hain.
Populate aliases: GET /api/content/book?populate=all and GET /api/content/book?populate=* currently behave like populate=relations.
Populate aliases: GET /api/content/book?populate=all aur GET /api/content/book?populate=* abhi populate=relations jaisa behave karte hain.
Populate scope: current populate is one level deep and does not recursively expand nested relations.
Populate scope: current populate one level deep hai aur nested relations ko recursively expand nahi karta.
RBAC populate rule: related entries are only expanded when the request role has get permission on the target schema.
RBAC populate rule: related entries tabhi expand hoti hain jab request role ke paas target schema par get permission ho.
Entry list relation summary: Admin UI shows related entry labels for single relations and selected counts plus labels for multi relations.
Entry list relation summary: Admin UI single relations ke related entry labels aur multi relations ke selected count plus labels dikhata hai.
Entry list queries: admin and dynamic list APIs support fields, search, limit, and offset for projected table-style reads.
Entry list queries: admin aur dynamic list APIs fields, search, limit, aur offset support karte hain projected table-style reads ke liye.
Example: GET /api/content/article?fields=title,views&search=Alpha&limit=50&offset=0 returns only selected fields with pagination metadata.
Example: GET /api/content/article?fields=title,views&search=Alpha&limit=50&offset=0 selected fields aur pagination metadata return karta hai.
Entry read projection: GET /api/content/article/ENTRY_ID?fields=title returns one entry with only the selected data field.
Entry read projection: GET /api/content/article/ENTRY_ID?fields=title ek entry ko sirf selected data field ke saath return karta hai.
Admin UI entries: collections are listed in the attached left submenu, selected collection data appears in a table, and visible fields can be selected per view.
Admin UI entries: collections attached left submenu me list hoti hain, selected collection data table me dikhta hai, aur visible fields per view choose ho sakte hain.
Admin UI entries: Create entry stays as a compact button until the user opens the generated form.
Admin UI entries: Create entry compact button rehta hai jab tak user generated form open nahi karta.
Admin UI query guide: Entries shows fields, search, limit, and offset examples for the selected collection.
Admin UI query guide: Entries selected collection ke liye fields, search, limit, aur offset examples dikhata hai.
Admin UI: Generated APIs lists every schema's dynamic content route.
Admin UI: Generated APIs har schema ka dynamic content route list karta hai.
Docs: dynamic API examples show list, create, update, and delete calls.
Docs: dynamic API examples list, create, update, aur delete calls dikhate hain.

RBAC

Roles: /api/admin/roles creates, lists, and reads API roles only; owner/admin panel roles stay hidden from this list.
Roles: /api/admin/roles sirf API roles create, list, aur read karta hai; owner/admin panel roles is list se hidden rahte hain.
Role catalogs: admin roles are owner, admin, schema-manager, user-manager; API roles include reader, single-reader, writer, editor, and public.
Role catalogs: admin roles owner, admin, schema-manager, user-manager hain; API roles me reader, single-reader, writer, editor, aur public hain.
Permissions: getAll, get, create, update, delete, realtime, and manage can be evaluated per API role and schema.
Permissions: getAll, get, create, update, delete, realtime, aur manage API role aur schema ke hisab se evaluate hote hain.
RBAC split: getAll controls GET list routes and get controls GET one-entry routes.
RBAC split: getAll GET list routes control karta hai aur get GET one-entry routes control karta hai.
Realtime permission controls WebSocket subscribe access; getAll remains a backward-compatible realtime fallback.
Realtime permission WebSocket subscribe access control karta hai; getAll backward-compatible realtime fallback rahta hai.
Manage permission: manage allows every content API action for that schema for API roles only.
Manage permission: manage sirf API roles ke liye us schema ke sab content API actions allow karta hai.
Settings: /adminui#settings opens an attached submenu for Admin Roles, Content Roles, Webhooks, and Realtime API.
Settings: /adminui#settings Admin Roles, Content Roles, Webhooks, aur Realtime API ke liye attached submenu kholta hai.
Enforcement: dynamic APIs accept x-apiagex-role-id or API role tokens and block missing permissions.
Enforcement: dynamic APIs x-apiagex-role-id ya API role tokens accept karte hain aur missing permissions block karte hain.
Users: /api/admin/users creates, lists, and reads users assigned to one API role.
Users: /api/admin/users one-API-role users create, list, aur read karta hai.
Admin UI: Users screen shows the user list first and opens create from a compact button.
Admin UI: Users screen pehle user list dikhata hai aur compact button se create open karta hai.
API tokens: /api/admin/roles/:roleId/tokens creates, lists, and revokes hashed content API tokens.
API tokens: /api/admin/roles/:roleId/tokens hashed content API tokens create, list, aur revoke karta hai.
Realtime API: /api/admin/realtime shows history, trusted backends create one-time rt_ tokens with POST /api/realtime/session, and WebSocket reconnect uses a fresh session plus lastEventId replay.
Realtime API: /api/admin/realtime history dikhata hai, trusted backend POST /api/realtime/session se one-time rt_ tokens banata hai, aur WebSocket reconnect fresh session plus lastEventId replay use karta hai.
RBAC blocked dynamic API requests return API_PERMISSION_DENIED.
RBAC blocked dynamic API requests API_PERMISSION_DENIED return karte hain.

Workflow API Calls

Workflow APIs: active workflows are mounted under /api/custom and use the same Settings > Custom API Permissions rules as code custom routes.
Workflow APIs: active workflows /api/custom ke under mount hote hain aur code custom routes jaise same Settings > Custom API Permissions rules use karte hain.
Public example setup: create an active POST workflow at /orders/status, open /adminui#settings/custom-api-permissions, select public, search workflow.orders.status.post, allow it, and save.
Public example setup: active POST workflow /orders/status banao, /adminui#settings/custom-api-permissions open karo, public select karo, workflow.orders.status.post search karo, allow karo, aur save karo.
Public curl: curl -X POST http://127.0.0.1:4000/api/custom/orders/status -H 'content-type: application/json' -d '{"orderId":"ord_123","status":"ready"}'.
Public curl: public allowed hone par Authorization header ki zarurat nahi hoti.
Token setup: allow the same workflow route for a content API role, create a token for that role in Settings > API Tokens, then call with Authorization: Bearer API_TOKEN.
Token setup: same workflow route ko content API role ke liye allow karo, Settings > API Tokens me us role ka token banao, phir Authorization: Bearer API_TOKEN ke saath call karo.
Token curl: curl -X POST http://127.0.0.1:4000/api/custom/orders/status -H 'Authorization: Bearer API_TOKEN' -H 'content-type: application/json' -d '{"orderId":"ord_123","status":"ready"}'.
Token curl: token role allowed nahi hai to 403 CUSTOM_API_PERMISSION_DENIED milega; token wrong ya revoked hai to API_TOKEN_INVALID milega.
Inactive workflow routes are not callable. Active workflow routes remain blocked until public or a token role is allowed.
Inactive workflow routes callable nahi hote. Active workflow routes tab tak blocked rehte hain jab tak public ya token role allow nahi hota.
Register template: Settings > Workflows can create an inactive POST /api/custom/auth/register starter that validates email/password, checks the users schema, creates an inactive user entry, and returns 201 or 409.
Register template: Settings > Workflows inactive POST /api/custom/auth/register starter bana sakta hai jo email/password validate karta hai, users schema check karta hai, inactive user entry banata hai, aur 201 ya 409 return karta hai.
Register template safety: create a users schema with email, passwordHash, and status fields first. The template does not store body.password; it writes PASSWORD_HASH_PLACEHOLDER_REPLACE_WITH_SERVER_SIDE_HASHING until real server-side hashing is added.
Register template safety: pehle email, passwordHash, aur status fields wala users schema banao. Template body.password store nahi karta; real server-side hashing add hone tak PASSWORD_HASH_PLACEHOLDER_REPLACE_WITH_SERVER_SIDE_HASHING likhta hai.
Practical guide: docs/workflow-builder-practical-guide.md shows the current schema, workflow steps, test run, permission allow, token, and curl flow.
Practical guide: docs/workflow-builder-practical-guide.md current schema, workflow steps, test run, permission allow, token, aur curl flow dikhata hai.
Browser check: docs/workflow-builder-browser-check.md covers owner login, schema, entries, workflow create, test run, activation, permission allow, token variant, and API call.
Browser check: docs/workflow-builder-browser-check.md owner login, schema, entries, workflow create, test run, activation, permission allow, token variant, aur API call cover karta hai.
Import/export plan: docs/workflow-import-export-plan.md covers versioning, validation, secret exclusion, compatibility, and inactive-by-default imports.
Import/export plan: docs/workflow-import-export-plan.md versioning, validation, secret exclusion, compatibility, aur inactive-by-default imports cover karta hai.
Release checkpoint: docs/workflow-builder-release-checkpoint.md lists the manual API flow, browser check, provider E2E, release gate, npm dry-runs, and publish rules.
Release checkpoint: docs/workflow-builder-release-checkpoint.md manual API flow, browser check, provider E2E, release gate, npm dry-runs, aur publish rules list karta hai.

QA

Admin UI redesign: /adminui uses a custom React shell with Dashboard, Schemas, Entries, APIs, Users, Settings, and Docs navigation.
Admin UI redesign: /adminui custom React shell use karta hai jisme Dashboard, Schemas, Entries, APIs, Users, Settings, aur Docs navigation hai.
Theme: the Admin UI has a light/dark toggle, shared design tokens, readable focus rings, and consistent status toasts.
Theme: Admin UI me light/dark toggle, shared design tokens, readable focus rings, aur consistent status toasts hain.
Workflow: core owner, schema, entry, API, relation, RBAC, and user flows remain in the Admin UI with responsive desktop/mobile layouts.
Workflow: core owner, schema, entry, API, relation, RBAC, aur user flows responsive desktop/mobile layouts ke saath Admin UI me rahte hain.
QA checklist: docs/admin-ui-visual-qa.md covers light/dark, desktop/mobile, nav, forms, lists, dialogs, relations, and RBAC expectations.
QA checklist: docs/admin-ui-visual-qa.md light/dark, desktop/mobile, nav, forms, lists, dialogs, relations, aur RBAC expectations cover karta hai.
Stabilization audit: docs/project-stabilization-audit.md covers practical flows, expected results, common errors, and current gaps.
Stabilization audit: docs/project-stabilization-audit.md practical flows, expected results, common errors, aur current gaps cover karta hai.
Smoke: npm run smoke covers owner login, schema, entry, dynamic API, role, user, and permission flow.
Smoke: npm run smoke owner login, schema, entry, dynamic API, role, user, aur permission flow cover karta hai.