{"activeVersionTag":"latest","latestAvailableVersionTag":"latest","collection":{"info":{"_postman_id":"90e13ffa-6ad7-49d6-80ac-2349c016730b","name":"Syntec Salesfunnel","description":"System services of the Enteprise module.  \nThese services are available in all other modules based of Syntec Enterprise\n\n## Authorization\n\nUse the User\\\\Auth service with a username / password to retrieve a JWT.  \nStore the JWT and RefreshToken .\n\nSend the JWT in every request as HEADER\n\njwt: {jwtToken}\n\nUse the service User/Logout to destroy the session (Not the JWT)\n\nWhen the JWT is expired use the User/Refresh token service to obtain a new JWT.\n\n## What **Syntec Enterprise** is (in one sentence)\n\n**Syntec Enterprise** is a **generic, metadata-driven enterprise backend platform** that provides **authentication, authorization, dynamic data modeling (entities), CRUD APIs, and configurable views**, which other Syntec modules (CRM, HRM, CMS, etc.) build upon.\n\nIt is **not** a single business application — it’s the **foundation layer**.\n\n## High-level architecture\n\nThink of Syntec Enterprise as a **low-code backend engine**:\n\n```\n[ Client / App / Integration ]\n            |\n            v\n[ REST API Layer ]\n   ├── User & Auth\n   ├── Entity Engine (tables as metadata)\n   ├── View Engine (SQL-like views)\n   └── Permissions & Roles\n            |\n            v\n[ Database with:\n  - Data\n  - Metadata about data\n  - Metadata about permissions ]\n\n ```\n\n# 1\\. Authentication & Session Management (`User`)\n\nThis part provides **identity and security**.\n\n### What it does\n\n- Authenticates users via **Basic Auth**\n    \n- Issues **JWT + RefreshToken**\n    \n- Tracks **sessions** (PHP session ID)\n    \n- Supports logout and token refresh\n    \n\n### Typical flow\n\n1. `POST /rest/userapi/auth`\n    \n    - username + password\n        \n    - returns JWT + refreshToken\n        \n2. Client stores JWT\n    \n3. JWT is sent on **every request** as header: ( jwt: {token} )\n    \n4. If expired → refresh via /rest/credentials/refresh\n    \n5. Logout destroys the session, not the JWT itself\n    \n\n👉 This is a **hybrid JWT + server-side session** model.\n\n# 2\\. Entity System (the core of everything)\n\nThis is the **most important concept**.\n\n### What is an “Entity” here?\n\nAn **Entity** is:\n\n- A database table (representing some real or conceptual object of interest)\n    \n- Fully described by **metadata stored in other tables**\n    \n- Governed by **field-level read/write permissions**\n    \n- Accessible through **generic CRUD APIs**\n    \n\nExample entities:\n\n- `s_prt` → Partners\n    \n- `s_prt_per` → Persons (appended to partner)\n    \n- `s_cfg` → Configuration\n    \n- `s_est` → Locations\n    \n- etc.\n    \n\n# 3\\. Entity Structure API (metadata introspection)\n\nEndpoints like:\n\n```\nGET /rest/systemapi/structure/\nGET /rest/systemapi/structure/{table}\n\n ```\n\n### What they do\n\nThey return **the data model itself**, including:\n\n- Fields\n    \n- Field types\n    \n- Lengths\n    \n- Defaults\n    \n- Required flags\n    \n- Indexes\n    \n- Foreign keys\n    \n- Computed fields\n    \n- **Read/write roles per field**\n    \n- Appended tables (1:1 extensions)\n    \n- Language tables (1:n translations)\n    \n\nThis allows:\n\n- Dynamic UI generation\n    \n- Generic CRUD\n    \n- Validation without hardcoding schemas\n    \n\n👉 The frontend does **not** need to know the database structure in advance.\n\n# 4\\. Entity CRUD API (generic data access)\n\nEndpoints like:\n\n```\nGET    /rest/systemapi/entity/{table}\nGET    /rest/systemapi/entity/{table}/{id|guid}\nPOST   /rest/systemapi/entity/{table}\n\n ```\n\n### Key properties\n\n- Same API works for **all tables**\n    \n- Supports:\n    \n    - Filtering\n        \n    - Sorting\n        \n    - Field selection\n        \n    - Pagination\n        \n- Permissions are enforced automatically\n    \n- Supports **ID or GUID**\n    \n- POST and PUT behave the same (idempotent save)\n    \n\n### Advanced features\n\n- Rich filter operators (`>=`, `!=`, `B=`, `R=`, date filters)\n    \n- Language tables handled automatically\n    \n- Appended tables saved automatically (e.g. Partner → Person)\n    \n\n👉 This is essentially a **dynamic ORM over HTTP**.\n\n# 5\\. Views (read-only, joined, business-friendly data)\n\nViews are **predefined, authorized, SQL-like result sets**.\n\nEndpoints:\n\n```\nGET /rest/systemapi/view\nGET /rest/systemapi/view/{guid}\nGET /rest/systemapi/textview/{guid}\n\n ```\n\n### Why views exist\n\nEntity lists:\n\n- ❌ No joins\n    \n- ❌ Raw technical fields and data\n    \n\nViews:\n\n- ✅ Joins\n    \n- ✅ Friendly column names (translated)\n    \n- ✅ Business logic\n    \n- ✅ Read-only\n    \n- ✅ CSV-like output possible\n    \n\n### Use cases\n\n- Dashboards\n    \n- Reports\n    \n- Exports\n    \n- Search screens\n    \n- Integrations\n    \n\n# 6\\. Roles & Authorization (very granular)\n\nAuthorization exists at **multiple levels**:\n\n| Level | Controlled |\n| --- | --- |\n| Table | Read / insert / update |\n| Field | Read / write |\n| View | Access allowed |\n| Action | Per role |\n\nRoles are numeric IDs, resolved dynamically.\n\n👉 This is **far beyond standard RBAC** — it’s **field-level security**.\n\n# 7\\. Why this system exists (the real goal)\n\nSyntec Enterprise exists to:\n\n- Avoid writing custom APIs per module\n    \n- Avoid duplicating CRUD logic\n    \n- Allow **configuration over code**\n    \n- Enable **rapid module development**\n    \n- Support **multiple domains** (CRM, HRM, CMS, etc.)\n    \n- Enforce security **without hardcoding**\n    \n\nIn short:\n\n**It’s a configurable enterprise data platform with a universal API.**\n\n# 8\\. Change Pointer System (Target-system synchronization)\n\nThe Change Pointer system in Syntec Enterprise is responsible for **detecting data changes and reliably synchronizing them with external target systems**, without coupling business logic to integrations.\n\n---\n\n### 8.1 Purpose\n\nThe Change Pointer mechanism ensures that:\n\n- Only **relevant data changes** are propagated\n    \n- Synchronization happens **asynchronously**\n    \n- Multiple systems can react to the **same change**\n    \n- Changes are **tracked, grouped, retried, and audited**\n    \n\n> It acts as a durable, database-backed integration queue. \n  \n\n---\n\n### 8.2 Configuration layer (what can trigger a change)\n\n#### Target systems (`s_chg_ptr_sys`)\n\nThe table **`s_chg_ptr_sys`** defines all supported target systems (e.g. ERP, CRM, DMS, external APIs).\n\nEach system is represented once and referenced by configuration and runtime records.\n\n---\n\n#### Field-level configuration (`s_chg_ptr_cfg`)\n\nThe table **`s_chg_ptr_cfg`** defines **which field changes matter** for which target system.\n\nIt links:\n\n- `s_chg_ptr_sys_id` → Target system\n    \n- `s_tab_id` → Source table\n    \n- `s_tab_fld_id` → Source field\n    \n\nThis enables configuration **per table, per field, per target system**, allowing extremely fine-grained control over outbound integrations.\n\n---\n\n### 8.3 Runtime behavior (change detection)\n\nWhen a record is **inserted or updated** via the Syntec ORM:\n\n1. The ORM compares the **previous and new values**\n    \n2. For each changed field, it checks `s_chg_ptr_cfg`\n    \n3. If a match exists:\n    \n    - A change pointer is **created or updated**\n        \n\n---\n\n### 8.4 Change Pointer aggregation logic (important)\n\nThe table **`s_chg_ptr`** enforces a **single open change pointer per table + item**.\n\n#### Key rules\n\n- There can be **only one record** in `s_chg_ptr` per:\n    \n    - `table_name`\n        \n    - `item_id`\n        \n    - **where** **`is_processed IS NULL`**\n        \n- When **another change occurs** on the _same record_ **before processing is completed**:\n    \n    - **No new row is inserted**\n        \n    - The existing row is **updated**\n        \n    - The changed field name is **added to** **`trigger_fields`** (comma-separated)\n        \n\nThis means:\n\nMultiple changes are **merged into one change pointer** until it is processed.\n\n---\n\n### 8.5 Processing model\n\nRecords in **`s_chg_ptr`** are **not processed automatically**.\n\nThey must be handled by:\n\n- A **Syntec CronJob**\n    \n- Or an **external processor / integration service**\n    \n\nTypical processing steps:\n\n1. is_processed IS NULLAND status = 1\n    \n2. It reads:\n    \n    - `table_name`\n        \n    - `item_id`\n        \n    - `trigger_fields`\n        \n    - `target_system`\n        \n3. It performs synchronization logic\n    \n4. On success:\n    \n    - `is_processed = 1`\n        \n    - `process_datetime` set\n        \n5. On failure:\n    \n    - `is_error = 1`\n        \n    - `process_message` populated\n        \n\n---\n\n### 8.6 New change after processing\n\nOnce a change pointer has been marked:\n\n```\nis_processed = 1\n\n ```\n\nThen:\n\n- A **new data change** on the same table/item_id\n    \n- Will result in:\n    \n    - **Insertion of a new row** in `s_chg_ptr`\n        \n    - With a fresh `trigger_fields` list\n        \n\nThis guarantees:\n\n- No loss of changes\n    \n- Clear separation between processing cycles\n    \n- Full historical traceability\n    \n\n---\n\n### 8.7 Structure of `s_chg_ptr`\n\nTypical fields include:\n\n| Field | Description |\n| --- | --- |\n| `table_name` | Source table |\n| `target_system` | Target system |\n| `item_id` | Changed record ID |\n| `trigger_fields` | Comma-separated list of changed fields |\n| `is_processed` | NULL = pending, 1 = processed |\n| `is_error` | Error indicator |\n| `process_datetime` | When processed |\n| `process_message` | Result or error details |\n| `created` / `modified` | Audit timestamps |\n| `status` | Logical record status |\n\n---\n\n### 8.8 Why this design matters\n\n✔ Prevents change flooding\n\n✔ Groups rapid updates intelligently\n\n✔ Guarantees idempotent processing\n\n✔ Enables retry & monitoring\n\n✔ Scales to many target systems\n\n✔ Fully auditable\n\n---\n\n### Summary (in one line)\n\n**Syntec Change Pointers form a smart, field-aware, aggregated, and resilient outbound integration queue**\n\n# 9\\. View Configuration System (Configurable read models)\n\nIn Syntec Enterprise, **Views** are not SQL files or hardcoded queries.\n\nThey are **fully metadata-driven read models** that define **what data is shown, how it is queried, who may see it, and which actions are available**.\n\nViews are the **primary mechanism for joined, business-friendly, read-only data access**.\n\n---\n\n### 9.1 Purpose of Views\n\nViews exist to:\n\n- Provide **joined datasets** (unlike entity lists)\n    \n- Expose **business-oriented column names**\n    \n- Enforce **role-based access**\n    \n- Enable **filters, sorting, exports, and actions**\n    \n- Decouple frontend data needs from database structure\n    \n\nA View is a _configurable SELECT statement with security and UX metadata attached_.\n\n---\n\n### 9.2 Core View Tables\n\n#### View header (`s_viw`)\n\nThe table **`s_viw`** defines the **identity and core behavior** of a view.\n\nIt contains:\n\n- View identity\n    \n- `s_pak_id` → Package / module ownership\n    \n- `s_frm_id` → Form or UI context\n    \n- Main database table\n    \n- Default order\n    \n- Other query-level defaults\n    \n\nThis table is the **root of all view configuration**.\n\n---\n\n#### View translations (`s_viw_lng`)\n\nThe table **`s_viw_lng`** contains:\n\n- Language-specific display names\n    \n- Per-language metadata for the same view\n    \n\nThis allows:\n\n- Multilingual UI labels\n    \n- One view definition, multiple languages\n    \n\n---\n\n### 9.3 Column configuration\n\n#### View columns (`s_viw_col`)\n\nThe table **`s_viw_col`** defines **which columns appear in the view**.\n\nEach record:\n\n- Is linked to a view (`s_viw_id`)\n    \n- Is linked to a field (`s_tab_fld`)\n    \n- Defines:\n    \n    - Visibility\n        \n    - Column position\n        \n    - Display behavior\n        \n\nThis allows:\n\n- Reordering columns without code\n    \n- Hiding technical fields\n    \n- Exposing only authorized business fields\n    \n\n---\n\n### 9.4 Authorization model for views\n\n#### View access (`s_viw_rol`)\n\nThe table **`s_viw_rol`** links:\n\n- `s_rol_id` → Role\n    \n- `s_viw_id` → View\n    \n\nThis determines **who may read the view at all**.\n\n> <p >If a user does not have a role linked here, the view does not exist for them.</p> \n  \n\n---\n\n#### Export authorization (`s_viw_export_rol`)\n\nThe table **`s_viw_export_rol`** controls:\n\n- Which roles may **export view data to CSV**\n    \n\nThis allows:\n\n- Read access without export access\n    \n- GDPR-safe restrictions on bulk data extraction\n    \n\n---\n\n### 9.5 Actions (bulk operations)\n\n#### View actions (`s_viw_act`)\n\nThe table **`s_viw_act`** defines **actions available on a view**.\n\nThese actions:\n\n- Appear as links or buttons in the UI\n    \n- Trigger **backend PHP logic**\n    \n- Are typically **bulk operations** (e.g. mass update, export, workflow trigger)\n    \n\nImportant:\n\n- The **action execution logic is not autogenerated**\n    \n- Backend PHP must be **implemented manually**\n    \n\n---\n\n#### Action authorization (`s_viw_act_rol`)\n\nThe table **`s_viw_act_rol`** links:\n\n- `s_rol_id` → Role\n    \n- `s_viw_act_id` → Action\n    \n\nThis controls **who may execute which action**.\n\n---\n\n### 9.6 Query definition (SQL generation)\n\nViews internally generate SQL using multiple metadata tables.\n\n#### Where clauses (`s_viw_where`)\n\nThe table **`s_viw_where`** contains:\n\n- Predefined WHERE conditions\n    \n- Static query constraints\n    \n- Business rules applied automatically\n    \n\nThese conditions are **always applied** when the view is queried.\n\n---\n\n#### Joins (`s_viw_jon`)\n\nThe table **`s_viw_jon`** defines:\n\n- JOINs for the main table\n    \n- Join type and conditions\n    \n- Linked tables\n    \n\nThis enables:\n\n- Complex multi-table views\n    \n- Business-level datasets without SQL in code\n    \n\n---\n\n### 9.7 User-defined filters\n\n#### Filter headers (`s_viw_filter`)\n\nThe table **`s_viw_filter`** defines:\n\n- Stored filters per **user (****`s_prt_id`****)**\n    \n- Linked to a specific view (`s_viw_id`)\n    \n- Named, reusable filter definitions\n    \n\nThis allows users to:\n\n- Save personal filters\n    \n- Reuse complex queries\n    \n- Switch filters quickly in the UI\n    \n\n---\n\n#### Filter values (`s_viw_filter_prt`)\n\nThe table **`s_viw_filter_prt`** contains:\n\n- Field operators\n    \n- Filter values\n    \n- Column-level filtering logic\n    \n\nTogether, these tables form **user-specific WHERE extensions** layered on top of the base view.\n\n---\n\n### 9.8 End-to-end view lifecycle\n\n1. View defined in `s_viw`\n    \n2. Columns configured in `s_viw_col`\n    \n3. Joins defined in `s_viw_jon`\n    \n4. Static filters applied via `s_viw_where`\n    \n5. Access restricted via `s_viw_rol`\n    \n6. Optional actions attached via `s_viw_act`\n    \n7. User filters layered via `s_viw_filter`\n    \n8. /rest/systemapi/view/{guid}\n    \n\n---\n\n### 9.9 Why this system matters\n\n✔ No hardcoded SQL\n\n✔ Multilingual support\n\n✔ Role-based visibility\n\n✔ User-defined filters\n\n✔ Secure exports\n\n✔ Extensible actions\n\n✔ Fully configurable without redeployments\n\n---\n\n### Summary (one sentence)\n\n**Syntec Views are metadata-driven, secure, multilingual, and extensible read models that bridge raw data and business-level insight.**\n\n# 10\\. Soft Delete & Record Lifecycle Management\n\nSyntec Enterprise uses a **soft delete strategy** across **all entities**.\n\nRecords are **never physically removed** from the database by default.\n\nInstead, record visibility and lifecycle are controlled via a standardized **`status`** field.\n\n---\n\n### 10.1 The `status` field (mandatory on every table)\n\nEvery Syntec entity table contains a column named:\n\n```\nstatus\n\n ```\n\nThis field defines the **logical lifecycle state** of a record.\n\n| Status | Meaning | Behavior |\n| --- | --- | --- |\n| `1` | **Active** | Record is visible and fully usable |\n| `2` | **Inactive (Deleted)** | Record is considered deleted |\n| `3` | **Archived** | Record is hidden from users but retained |\n\n---\n\n### 10.2 Visibility rules\n\n- **Status = 1 (Active)**\n    \n    - Visible in views\n        \n    - Queryable via entity APIs\n        \n    - Fully editable (subject to permissions)\n        \n- **Status = 2 (Inactive / Deleted)**\n    \n    - Treated as deleted\n        \n    - Excluded from normal views and queries\n        \n    - Retained for audit, rollback, or historical reference\n        \n- **Status = 3 (Archived)**\n    \n    - Not visible to end users\n        \n    - Not marked as deleted\n        \n    - Typically used for:\n        \n        - Historical records\n            \n        - Closed periods\n            \n        - Compliance retention\n            \n\n> <p >Physical deletion is intentionally avoided to preserve data integrity and traceability.</p> \n  \n\n---\n\n### 10.3 Soft delete operation\n\nSoft deleting a record is performed by **updating the entity**, not by calling a delete endpoint.\n\nExample:\n\n```\nPOST /rest/systemapi/entity/{table}\n{\n  \"data\": {\n    \"{table}\": {\n      \"id\": 123,\n      \"status\": 2\n    }\n  }\n}\n\n ```\n\nThis immediately:\n\n- Marks the record as **inactive**\n    \n- Removes it from user-visible views\n    \n- Preserves all data\n    \n\nNo special delete API is required.\n\n---\n\n### 10.4 Integration with other systems\n\nSoft deletes are **first-class changes** in Syntec and therefore:\n\n- Can trigger **Change Pointers** (Point 8)\n    \n- Can be synchronized to external systems\n    \n- Are auditable\n    \n- Are reversible (by setting status back to `1`)\n    \n\n---\n\n### 10.5 Why soft deletes are mandatory in Syntec\n\n✔ Prevents accidental data loss\n\n✔ Enables audit trails\n\n✔ Supports regulatory compliance\n\n✔ Allows recovery and rollback\n\n✔ Preserves referential integrity\n\n✔ Works seamlessly with change pointers\n\n---\n\n### Summary (one line)\n\n**In Syntec, deleting data means changing state — not removing records.**\n\n# 11\\. Form Layout & UI Configuration System\n\nSyntec Enterprise provides a **fully configurable form layout engine** that allows screens and input forms to be defined **entirely through metadata**, without frontend code changes.\n\nForms control **how entities are edited and viewed**, while still respecting **entity-level security rules**.\n\n---\n\n### 11.1 Purpose of the Form system\n\nThe Form configuration system exists to:\n\n- Define **screen layouts** without hardcoding UI\n    \n- Control **field visibility and positioning**\n    \n- Apply **role-based access** at form level\n    \n- Provide **user guidance and documentation**\n    \n- Decouple UI structure from database structure\n    \n\nForms are **presentation models**, layered on top of entities.\n\n---\n\n### 11.2 Core Form Tables\n\n#### Form header (`s_frm`)\n\nThe table **`s_frm`** defines the **form itself**.\n\nIt contains:\n\n- Form identity\n    \n- Optional link to a main entity table (`s_tab`)\n    \n- General form metadata (context, usage)\n    \n\nA form can exist:\n\n- As an **entity-bound form**\n    \n- Or as a **standalone UI structure**\n    \n\n---\n\n#### Form translations (`s_frm_lng`)\n\nThe table **`s_frm_lng`** provides:\n\n- Display names per language\n    \n- Multilingual form titles\n    \n\nThis allows a single form to be reused across locales.\n\n---\n\n### 11.3 Form field configuration\n\n#### Form fields (`s_frm_fld`)\n\nThe table **`s_frm_fld`** defines **individual UI fields** on a form.\n\nEach record controls:\n\n- Field type (text input, select box, checkbox, etc.)\n    \n- Absolute positioning:\n    \n    - Top\n        \n    - Left\n        \n    - Width\n        \n    - Label width\n        \n- Optional link to:\n    \n    - `s_tab_fld_id` (entity field)\n        \n\nThis enables:\n\n- Visual layout control\n    \n- Binding UI fields to entity data\n    \n- UI-only fields (not stored in DB)\n    \n\n---\n\n#### Form field translations (`s_frm_fld_lng`)\n\nThe table **`s_frm_fld_lng`** defines:\n\n- Language-specific field labels\n    \n- Translated display names\n    \n\nThis ensures multilingual UI consistency.\n\n---\n\n### 11.4 Authorization layering (important)\n\nForm-level authorization exists but **never overrides entity security**.\n\n#### Read authorization (`s_frm_fld_rol_rd`)\n\nThe table **`s_frm_fld_rol_rd`** links:\n\n- `s_frm_fld_id`\n    \n- `s_rol_id`\n    \n\nThis determines **whether a field is visible on a form**.\n\n**Important rule:**\n\nIf `s_tab_fld_rol_rd` denies read access, the field is hidden regardless of form configuration.\n\n---\n\n#### Write authorization (`s_frm_fld_rol_wr`)\n\nThe table **`s_frm_fld_rol_wr`** links:\n\n- `s_frm_fld_id`\n    \n- `s_rol_id`\n    \n\nThis determines **whether a field is editable on the form**.\n\n**Important rule:**\n\nEntity-level write authorization (`s_tab_fld_rol_wr`) always has priority.\n\n---\n\n### 11.5 Fieldsets & layout grouping\n\n#### Form fieldsets (`s_frm_fst`)\n\nThe table **`s_frm_fst`** defines **visual field groupings**.\n\nCharacteristics:\n\n- Absolute positioning\n    \n- Used for layout organization\n    \n- No direct link to entity fields\n    \n- Fields are placed visually within fieldsets\n    \n\nThis enables:\n\n- Logical grouping\n    \n- Better UX\n    \n- Sectioned forms without data coupling\n    \n\n---\n\n### 11.6 Field documentation & help\n\n#### Field documentation (`s_frm_fid_doc`)\n\nThe table **`s_frm_fid_doc`** links:\n\n- `s_frm_fld_id`\n    \n- Documentation or explanation text\n    \n\nIn the UI:\n\n- Shown via an **“I” (info) button**\n    \n- Provides context, instructions, or business rules\n    \n\nThis supports:\n\n- User onboarding\n    \n- Reduced training needs\n    \n- Inline documentation\n    \n\n---\n\n### 11.7 Form vs Entity responsibilities\n\n| Aspect | Entity | Form |\n| --- | --- | --- |\n| Data storage | ✅ | ❌ |\n| Validation | ✅ | ❌ |\n| Security (final) | ✅ | ❌ |\n| Layout | ❌ | ✅ |\n| UX labels | ❌ | ✅ |\n| Field positioning | ❌ | ✅ |\n\nForms **present** data — entities **own** data.\n\n---\n\n### 11.8 Why this system matters\n\n✔ No frontend redeployments\n\n✔ Metadata-driven UI\n\n✔ Multilingual forms\n\n✔ Role-based field access\n\n✔ Entity security remains authoritative\n\n✔ Built-in user guidance\n\n---\n\n### Summary (one sentence)\n\n**Syntec Forms are configurable, secure, multilingual UI definitions layered on top of entity data.**\n\n## Mental model (simple)\n\nIf you had to explain it to another developer:\n\n> “Syntec Enterprise is like a database-driven backend where tables, fields, permissions, and even views are data themselves. The API never changes — only the configuration does.”","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","isPublicCollection":false,"owner":"14351770","team":1765624,"collectionId":"90e13ffa-6ad7-49d6-80ac-2349c016730b","publishedId":"2sBXVkBV5Y","public":true,"publicUrl":"https://documenter-api.postman.tech/view/14351770/2sBXVkBV5Y","privateUrl":"https://go.postman.co/documentation/14351770-90e13ffa-6ad7-49d6-80ac-2349c016730b","customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"documentationLayout":"classic-double-column","customisation":{"metaTags":[{"name":"description","value":""},{"name":"title","value":""}],"appearance":{"default":"light","themes":[{"name":"dark","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"FF6C37"}},{"name":"light","logo":null,"colors":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"}}]}},"version":"8.12.12","publishDate":"2026-01-23T03:21:07.000Z","activeVersionTag":"latest","documentationTheme":"light","metaTags":{"title":"","description":""},"logos":{"logoLight":null,"logoDark":null}},"statusCode":200},"environments":[{"name":"Default environment","id":"cca99027-8c07-4d8c-be73-fb144617aa30","owner":"14351770","values":[{"key":"baseUrl","value":"","enabled":true,"type":"default"},{"key":"username","value":"","enabled":true,"type":"default"},{"key":"password","value":"","enabled":true,"type":"default"},{"key":"refreshToken","value":"","enabled":true,"type":"default"},{"key":"jwt","value":"","enabled":true,"type":"default"},{"key":"passwordToken","value":"","enabled":true,"type":"default"}],"published":true}],"user":{"authenticated":false,"permissions":{"publish":false}},"run":{"button":{"js":"https://run.pstmn.io/button.js","css":"https://run.pstmn.io/button.css"}},"web":"https://www.getpostman.com/","team":{"logo":"https://res.cloudinary.com/postman/image/upload/t_team_logo_pubdoc/v1/team/c49084d249e167976bb9fc4443a2f5a0bbda0457add64c05860e294a59cf5765","favicon":"https://res.cloudinary.com/postman/image/upload/v1737660981/team/972940f3cb78fd927889d912a341e432.ico"},"isEnvFetchError":false,"languages":"[{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"HttpClient\"},{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"RestSharp\"},{\"key\":\"curl\",\"label\":\"cURL\",\"variant\":\"cURL\"},{\"key\":\"dart\",\"label\":\"Dart\",\"variant\":\"http\"},{\"key\":\"go\",\"label\":\"Go\",\"variant\":\"Native\"},{\"key\":\"http\",\"label\":\"HTTP\",\"variant\":\"HTTP\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"OkHttp\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"Unirest\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"Fetch\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"jQuery\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"XHR\"},{\"key\":\"c\",\"label\":\"C\",\"variant\":\"libcurl\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Axios\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Native\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Request\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Unirest\"},{\"key\":\"objective-c\",\"label\":\"Objective-C\",\"variant\":\"NSURLSession\"},{\"key\":\"ocaml\",\"label\":\"OCaml\",\"variant\":\"Cohttp\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"cURL\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"Guzzle\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"HTTP_Request2\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"pecl_http\"},{\"key\":\"powershell\",\"label\":\"PowerShell\",\"variant\":\"RestMethod\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"http.client\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"Requests\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"httr\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"RCurl\"},{\"key\":\"ruby\",\"label\":\"Ruby\",\"variant\":\"Net::HTTP\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"Httpie\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"wget\"},{\"key\":\"swift\",\"label\":\"Swift\",\"variant\":\"URLSession\"}]","languageSettings":[{"key":"csharp","label":"C#","variant":"HttpClient"},{"key":"csharp","label":"C#","variant":"RestSharp"},{"key":"curl","label":"cURL","variant":"cURL"},{"key":"dart","label":"Dart","variant":"http"},{"key":"go","label":"Go","variant":"Native"},{"key":"http","label":"HTTP","variant":"HTTP"},{"key":"java","label":"Java","variant":"OkHttp"},{"key":"java","label":"Java","variant":"Unirest"},{"key":"javascript","label":"JavaScript","variant":"Fetch"},{"key":"javascript","label":"JavaScript","variant":"jQuery"},{"key":"javascript","label":"JavaScript","variant":"XHR"},{"key":"c","label":"C","variant":"libcurl"},{"key":"nodejs","label":"NodeJs","variant":"Axios"},{"key":"nodejs","label":"NodeJs","variant":"Native"},{"key":"nodejs","label":"NodeJs","variant":"Request"},{"key":"nodejs","label":"NodeJs","variant":"Unirest"},{"key":"objective-c","label":"Objective-C","variant":"NSURLSession"},{"key":"ocaml","label":"OCaml","variant":"Cohttp"},{"key":"php","label":"PHP","variant":"cURL"},{"key":"php","label":"PHP","variant":"Guzzle"},{"key":"php","label":"PHP","variant":"HTTP_Request2"},{"key":"php","label":"PHP","variant":"pecl_http"},{"key":"powershell","label":"PowerShell","variant":"RestMethod"},{"key":"python","label":"Python","variant":"http.client"},{"key":"python","label":"Python","variant":"Requests"},{"key":"r","label":"R","variant":"httr"},{"key":"r","label":"R","variant":"RCurl"},{"key":"ruby","label":"Ruby","variant":"Net::HTTP"},{"key":"shell","label":"Shell","variant":"Httpie"},{"key":"shell","label":"Shell","variant":"wget"},{"key":"swift","label":"Swift","variant":"URLSession"}],"languageOptions":[{"label":"C# - HttpClient","value":"csharp - HttpClient - C#"},{"label":"C# - RestSharp","value":"csharp - RestSharp - C#"},{"label":"cURL - cURL","value":"curl - cURL - cURL"},{"label":"Dart - http","value":"dart - http - Dart"},{"label":"Go - Native","value":"go - Native - Go"},{"label":"HTTP - HTTP","value":"http - HTTP - HTTP"},{"label":"Java - OkHttp","value":"java - OkHttp - Java"},{"label":"Java - Unirest","value":"java - Unirest - Java"},{"label":"JavaScript - Fetch","value":"javascript - Fetch - JavaScript"},{"label":"JavaScript - jQuery","value":"javascript - jQuery - JavaScript"},{"label":"JavaScript - XHR","value":"javascript - XHR - JavaScript"},{"label":"C - libcurl","value":"c - libcurl - C"},{"label":"NodeJs - Axios","value":"nodejs - Axios - NodeJs"},{"label":"NodeJs - Native","value":"nodejs - Native - NodeJs"},{"label":"NodeJs - Request","value":"nodejs - Request - NodeJs"},{"label":"NodeJs - Unirest","value":"nodejs - Unirest - NodeJs"},{"label":"Objective-C - NSURLSession","value":"objective-c - NSURLSession - Objective-C"},{"label":"OCaml - Cohttp","value":"ocaml - Cohttp - OCaml"},{"label":"PHP - cURL","value":"php - cURL - PHP"},{"label":"PHP - Guzzle","value":"php - Guzzle - PHP"},{"label":"PHP - HTTP_Request2","value":"php - HTTP_Request2 - PHP"},{"label":"PHP - pecl_http","value":"php - pecl_http - PHP"},{"label":"PowerShell - RestMethod","value":"powershell - RestMethod - PowerShell"},{"label":"Python - http.client","value":"python - http.client - Python"},{"label":"Python - Requests","value":"python - Requests - Python"},{"label":"R - httr","value":"r - httr - R"},{"label":"R - RCurl","value":"r - RCurl - R"},{"label":"Ruby - Net::HTTP","value":"ruby - Net::HTTP - Ruby"},{"label":"Shell - Httpie","value":"shell - Httpie - Shell"},{"label":"Shell - wget","value":"shell - wget - Shell"},{"label":"Swift - URLSession","value":"swift - URLSession - Swift"}],"layoutOptions":[{"value":"classic-single-column","label":"Single Column"},{"value":"classic-double-column","label":"Double Column"}],"versionOptions":[],"environmentOptions":[{"value":"0","label":"No Environment"},{"label":"Default environment","value":"14351770-cca99027-8c07-4d8c-be73-fb144617aa30"}],"canonicalUrl":"https://documenter.gw.postman.com/view/metadata/2sBXVkBV5Y"}