Skip to content

API — Platform Modules

Endpoints

Endpoint Method Purpose Source file
/platform/modules GET Platform home page module list — pre-ordered platformService.tsx (getOrderedModules)
/iqv_platform_modulleri GET List all platform modules (legacy endpoint) platformService.tsx (getModules)
/iqv_platform_modul_ekle POST Add a new platform module platformService.tsx (createModule)
/iqv_platform_modul_guncelle PUT Update an existing module platformService.tsx (updateModule)
/iqv_platform_sil DELETE (body { id }) Delete a module platformService.tsx (deleteModule)
/platform-queue-list POST (body { company_id, organization_id }) Fetch the saved card ordering platformQueueService.tsx (getPlatformQueue)
/platform-queue-create POST Save a new card ordering platformQueueService.tsx (savePlatformQueue)
/platform-reminder-list POST List platform reminders platformReminderService.tsx (listPlatformReminders)
/platform-reminder-update POST Create/update a platform reminder platformReminderService.tsx (savePlatformReminder)
/platform-reminder-delete DELETE (body) Delete a platform reminder platformReminderService.tsx (deletePlatformReminder)

GET /platform/modules — Node.js Platform Backend

The Node.js counterpart of the Node-RED [GET] /iqv_platform_modulleri flow. Its public address is /api/v1/platform/modules: the central Axios client's baseURL (VITE_PLATFORM_API_BASE_URL) already ends with /api/v1, so the internal route is defined as just /platform/modules (routers/platform.routes.ts). Authorization: Bearer <token> is required; it takes no query parameters and no body.

{
  "success": true,
  "message": "Platform modülleri listelendi",
  "data": [{ "_id": "", "id": "", "name": "", "url": "", "order": 0, "created_by_id": "", "created_at": "", "updated_at": "" }]
}

On failure the existing standard is kept: { "success": false, "message": "Platform modülleri alınamadı" }.

Listing rules (all backend-side — services/platform.service.ts):

  1. Modules are read from the platform-data collection (name from .env → MONGODB_PLATFORM_COLLECTION; auto-detected when unset).
  2. Records with an empty id or name are dropped.
  3. Ordering comes from the platform-queue structure: the most recent document for the scope (JWT company_id / organization_id) is selected and its items are de-duplicated per module_id.
  4. Modules with a valid (positive) and unique queue_number in the saved ordering come first, in ascending order.
  5. Then records carrying the collection's order field, sorted order ASC; ties are broken by created_at ASC. order: 0 is a valid value and is never dropped.
  6. Records with no parseable order are appended last, in created_at ASC order; unparseable dates go last.

order is the raw value; the array order is the ordering

The order in the response is the raw collection field (including 0; null when absent). The on-screen order comes from the array order, not from this field — the client never re-sorts. Priority: saved ordering → order → created_at.

Migration rule

/iqv_platform_modulleri (Node-RED) has not been removed. The Notes, Reminder and Settings pages still read the module list from it; only the Platform home page moved to the new endpoint. The Node-RED connection will be removed once the new endpoint is verified and all consumers are migrated.

Caching

getModules results are held in a 60-second stale-while-revalidate in-memory cache with in-flight request dedup; the cache is invalidated after creating/updating/deleting a module (invalidateModulesCache).

getOrderedModules (the new endpoint) uses the same pattern under a separate key (iqvizyon-platforms-ordered). In addition to module mutations, it is also invalidated when an ordering is saved (savePlatformQueue → invalidateOrderedModulesCache), so a new order saved on Settings > Sort shows up on the Platform page without waiting.

Saving Ordering — Client-Side Validation

Before savePlatformQueue is called, validateQueueItems runs these checks entirely without a network request: the list can't be empty, no duplicate module_id, the submitted items must exactly match the expected module set, and queue_number values must be unique and contiguous across 1..N.

POST /platform-queue-create Request Body

Alongside sort_mode, organization_id, company_id, items, updated_by_id, updated_by_name, there is one more fixed field sent to the backend for categorization: source: 'termit-platform-queue'.

Backend contract — intentionally left unchanged

This literal value is a fixed contract field the backend expects for categorizing records. As part of the project rename, this kind of contract value was deliberately not changed, since doing so without backend-side coordination could break the real integration. See the "Left unchanged due to backend contract" section in the main report for details.