canonical: https://jentic.com/apis/luminjo.com/luminjo

# Luminjo API

Jentic publishes the only available OpenAPI specification for Luminjo API, keeping it validated and agent-ready. Luminjo is a customer support ticket management system, and the API exposes 26 endpoints across tickets, folders, FAQs, users, tags, typical responses, and attachments. Authentication uses the Authorization header as an API key. The API supports the full ticket lifecycle plus the supporting catalogues (tags, folders, FAQs, canned responses) that a support team uses day to day.

## For AI agents

Manage Luminjo support tickets end to end - create, list, update, tag, attach files, post canned responses, and organise them into folders.

## Scope

Does not handle live chat, voice calls, or in-product messaging - use for Luminjo support ticket, folder, tag, FAQ, user, typical-response, and attachment management only.

## Capabilities

- List, create, retrieve, update, and delete support tickets via `/api/ticket` and `/api/ticket/{id}`
- Organise tickets into folders with full CRUD on `/api/folder`
- Tag tickets and manage the tag catalogue used for filtering and reporting
- Maintain a library of typical (canned) responses agents reuse on common tickets
- Attach files to tickets and look up the attachments associated with a ticket
- List FAQs and users to power help-centre and assignment workflows

## Use cases

### Ingest support tickets from email or chat

Inbound channels such as email forwarders or web chat widgets can post each new conversation into Luminjo as a ticket via POST `/api/ticket.` The created ticket can be placed in a folder and tagged in the same workflow, so the support team sees a fully classified item rather than a raw email blob. Folders and tags are managed through their own CRUD endpoints, keeping the catalogue consistent.

Example prompt: POST `/api/ticket` with the customer email body and subject, then PATCH `/api/ticket/{id}` to apply the billing folder and the 'invoice' tag.

### Reply with canned typical responses

Support agents reuse a library of typical responses for common questions (refund process, password reset, shipping status). The Typical Responses endpoints expose the catalogue, and the agent or AI assistant picks the right response and posts it onto the ticket. This keeps tone consistent and shortens handle time for repeated issues.

Example prompt: List typical responses, choose the 'refund process' template, and apply it to ticket 12345.

### Reporting and tag-based segmentation

Operations teams report on volume and resolution time by tag and folder. Pulling `/api/ticket` with filters, joined with the tag and folder catalogues, gives a structured dataset for a BI tool or dashboard - without touching the Luminjo UI or scraping its admin pages.

Example prompt: Pull `/api/ticket` and group by tag to return a count of tickets per tag for the last 7 days.

### Agent-driven Luminjo triage via Jentic

An AI triage agent reads each new ticket, decides on a folder and tag, and replies with a typical response when the question is routine - escalating to a human otherwise. Jentic stores the Luminjo Authorization API key in your Jentic One instance and exposes the create-ticket, update-ticket, and typical-response operations by intent so the agent can chain them without holding the raw key.

Example prompt: Search Jentic for 'update luminjo ticket', load PATCH `/api/ticket/{id}`, and execute it to set the folder, tag, and assignee on a freshly created ticket.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/api/ticket` | List all tickets |
| POST | `/api/ticket` | Create a new ticket |
| PATCH | `/api/ticket/{id}` | Update a ticket |
| DELETE | `/api/ticket/{id}` | Delete a ticket |
| GET | `/api/folder` | List all folders |
| GET | `/api/tag` | List all tags |
| GET | `/api/faq` | List FAQs |

## Key resources

- **Tickets** — Full CRUD on support tickets
- **Folders** — Folder CRUD for organising tickets
- **Tags** — Tag catalogue for filtering and reporting
- **Typical Responses** — Library of canned response templates
- **Attachments** — File attachments associated with tickets
- **FAQs** — Read-only list of FAQs
- **Users** — Read-only list of users available for assignment

## Why Jentic

- **Setup:** Wiring the Luminjo API by hand means sending its API key header on every request and coordinating it across ticket, folder, tag, and FAQ paths on your Luminjo instance host. Through Jentic you install once, import the Luminjo API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** You choose which Luminjo operations the agent may call, so you can limit it to the ones it needs, such as listing or creating tickets, and leave out destructive ones like deleting a ticket unless you add them. The agent only reaches the operations in the set you allow.
- **Credential handling:** Your Luminjo key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Luminjo ticket' or 'apply a tag to a ticket', and Jentic returns the matching Luminjo operation with its parameter schema so the agent calls the right endpoint directly.

## Related APIs

- **Zendesk** — Mature help-desk platform with a large ecosystem and per-seat pricing
- **Freshdesk** — Help-desk platform with similar ticket, folder, and canned-reply primitives
- **Help Scout** — Inbox-style support tool with a similar ticket and tag model

## FAQ

### Why is there no official OpenAPI spec for Luminjo API?

Luminjo does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Luminjo API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Luminjo API use?

The Luminjo API uses an Authorization header carrying an API key. Each request to the Luminjo workspace base URL must include the header. Through Jentic, the key is stored encrypted in your Jentic One instance and injected per request so it never appears in the agent's prompt or logs.

### Can I create and tag a ticket in one workflow?

Yes. POST `/api/ticket` creates the ticket, then PATCH `/api/ticket/{id}` updates it with the chosen folder and tags, drawn from the catalogues exposed by `/api/folder` and `/api/tag.` Doing both in sequence is the standard pattern for ingesting a fully classified ticket.

### What are the rate limits for the Luminjo API?

Specific rate limits are not declared in this spec. Expect per-workspace caps consistent with a help-desk product - design clients to back off on 429 responses and avoid polling `/api/ticket` more aggressively than once per minute per filter.

### How do I send a typical response to a ticket through Jentic?

Search Jentic for 'luminjo typical response', load the matching operation against `/api/typical-response` or apply the chosen template via PATCH `/api/ticket/{id}`, and execute it with the ticket ID and response payload. Jentic injects the Authorization API key automatically.

### Can I limit what my agent is allowed to do with the Luminjo API?

Yes. Jentic One is self-hosted by you, so your own rules decide which Luminjo operations and credentials the agent may use. You can allow only the operations it needs, such as listing tickets with GET `/api/ticket` or creating one with POST `/api/ticket`, and leave out destructive calls like DELETE `/api/ticket/{id}` unless you explicitly add them. The agent can only reach the operations in the set you permit, so it never touches folders, tags, or ticket deletion that you have not enabled.