Support Tickets API — Current Internal Routes & v1 Boundary

EarthCoop has a real support-ticket domain and current application/API routes for ticket workflows. At the current application baseline, however, ticket endpoints are not registered in the /api/v1 native route set. This distinction prevents documentation from treating legacy/internal ticket routes as a versioned v1 contract merely because v1 bearer authentication now exists elsewhere.

Current support-domain behavior

The support subsystem includes:

member ticket creation and listing;
ticket detail/history access under ownership rules;
comments and attachments while the current ticket state permits them;
member close behavior for eligible tickets;
staff/admin support processing;
conditional NajmHoda escalation integration.

The member-facing UI is currently under /tickets.

Versioned API status

Current /api/v1 covers native authentication, bootstrap/current-user, notifications/push, selected geography, NajmHoda messaging and media delivery. Ticket routes are not in that route file today.

Therefore:

current support API/application route ≠ current /api/v1 ticket contract
v1 bearer token existence ≠ every /api route becomes v1

Do not build a native or third-party integration by prepending /api/v1 to an older ticket endpoint. Use only routes actually registered in the current versioned contract.

Ticket ownership and authorization

A ticket belongs to a support context and member/account relationship. Knowing a ticket ID, tracking code, comment ID or attachment path does not grant access. The support domain must enforce the current ownership and staff authorization rules.

Comments and closed tickets

The current member controller does not allow a new member comment on a closed ticket. Documentation must not claim that commenting automatically reopens a closed case.

If reopening becomes an explicit future workflow, it should be documented from that new contract rather than inferred from an older guide.

Attachments

Comments/tickets can carry attachments under current validation/storage policy. File type, size and storage details are operational controls and can change; external documentation should not freeze an old extension list as a permanent API guarantee.

NajmHoda escalation

NajmHoda can conditionally create or associate support information through the configured escalation service. Chat escalation is policy-driven and does not mean every assistant message automatically creates a ticket.

Authentication note

The current v1 native authentication guide documents how EarthCoop issues and revokes bearer tokens for the v1 client boundary. That does not independently publish a versioned ticket API. Any current unversioned support endpoint must be evaluated under its own route, middleware and intended first-party use.

Future versioning

If support tickets are promoted into /api/v1 or a later version, the published contract should explicitly define the supported methods, request/response schemas, authorization, attachment rules and compatibility expectations. Until then, this page documents the current implementation boundary rather than inventing that contract.