POST /tms/transloads/loader-telegram

TMS > tms.transload

What it does

/tms/transloads/loader-telegram accepts POST and is declared in app/systems/TMS/transload/api_routes.php:549 as a path.

The route handler delegates to tmsTransloadApiLoaderTelegramSend(). That function is the owner of this behaviour; the route entry is only dispatch.

Call chain:

1. → tmsTransloadApiLoaderTelegramSend() — app/systems/TMS/transload/form_mutation_api_helper.php:25
2. ↳ tmsTransloadApiParseRecipients() — app/systems/TMS/transload/form_mutation_api_helper.php:2

Who calls it

Called from:

• frontend/pages/system/TMS/transload/inbound-planning.php
• frontend/pages/system/TMS/transload/loader-assignment-board.php

A caller is the strongest available evidence of the intended use.

Input

Where	Key
body	MESSAGE
body	PLANNER_ID
body	RECIPIENTS
body	RECIPIENT_TYPE
body	TRANSLOAD_ID

Request bodies must not use TYPE, ACTION or USERNAME as contract fields.

Output

Key
LAST_SENT_TIME
PLANNER_ID
TRANSLOAD_ID

Success is { "data": …, "requestId": "…" }. Failure is { "error": { "code", "message" }, "requestId": "…" }.

Data

Tables reached from the owner function:

• T_LOADING_PLANNER

Access

• module-gated on tms.transload, so tenant module access applies

Validation and failure messages

• TRANSLOAD_ID is required.
• Telegram message is required.
• Only USER_ID Telegram recipients are supported for loader dispatch.
• Telegram recipients are required.
• Planner row changed. Reload and try again.

These strings come from the owner function and are the messages a client can receive. They are also the cheapest way to tell a rejected request from a broken one.