Lepsto Support
Store customer conversations and answer them through the Support App or API.
Lepsto Support stores your product’s customer conversations and gives your team tools to answer them. Your backend opens a thread for an end user, your team replies, and the thread moves through the statuses you define. Labels organize the queue; agent profiles identify the people and bots replying.
Support provides the backend. Your product renders the customer-facing conversation, while your team can work in the separate Support App in the Lepsto workspace, through MCP, or through the REST API.
Two contours that never mix
Support separates the identity making an API call from the end user the conversation is about.
The caller is on your side: a specialist signed in to Lepsto, your backend, or a bot. Authentication establishes whether the call is allowed and which product it can access.
The end user is identified by authorExternalId, an identifier from your own user base, plus an optional display name. Support stores these values verbatim without resolving, normalizing, or enriching them. It provides no end-user directory, login, signup, or session. A message therefore names either an external author or a Support agent profile; its author field is not a Lepsto account.
Product, thread, message, status, agent
Every Support record belongs to one product. A record belonging to another product returns not found, without revealing its owner. Products themselves are managed on the platform.
A thread is a conversation: a ticket for a problem the end user wants fixed, or feedback for unsolicited input. It has a title, priority (low, normal, high, or urgent), labels, your free-form metadata, an optional integer rating from 0 to 10, and at most one assigned agent.
A message is an entry in a thread, read oldest first. It has exactly one external or agent author. Its direction (inbound or outbound) and visibility (public or internal) are independent of that author and of each other. For example, you can record a customer’s phone call as an inbound internal note. Edits save revisions; deletion leaves a placeholder.
A status records the thread’s progress. A label is a tag. An agent is the profile shown beside a reply.
- Threads and messages explains creation, filtering, authorship, and visibility.
- Correct or remove a message covers edits, soft deletion, and history.
- Statuses explains categories and archiving.
- Agents covers profiles, assignment, and deactivation.
- Labels and attachments shows how to tag a thread and send a file.
The status dictionary
You choose each status’s name, color, and display order. Support uses its category for automation and reporting: open, pending, resolved, or closed. Renaming a pending status to “Waiting on customer” leaves its behavior unchanged.
The first dictionary read seeds four statuses, one per category, in that order. New threads use the non-archived open status with the lowest display order; creation has no status override. After creation, any live status can follow any other.
A status’s category cannot change while a thread references it. To retire a status, archive it and choose another live status in the same product. Support moves its threads and archives the status in one transaction. Archived statuses cannot receive threads.
There is one automatic transition: a public inbound message on a pending thread moves it to the default open status. Internal notes and outbound messages do not trigger this rule. The category determines the behavior, including for custom status names.
Labels and agents
Labels have names unique within the product and carry no built-in automation. Updating a thread’s labels replaces the whole set. Filtering by two labels returns threads with both.
Agent profiles have a display name, optional job title, and optional avatar. You can bind a profile to a Lepsto identity or leave it unbound for a bot or backend. Support stores the binding verbatim without checking whether the account exists. Each Lepsto identity can be bound to at most one agent per product.
Threads start unassigned. Assignment sets one agent; passing null clears it. Agents are deactivated rather than deleted: their messages and existing assignments remain, but they cannot receive new assignments.
Attachments
To send a file, reserve it against a thread, PUT its bytes to the returned signed URL with the required headers, then confirm the upload. Support checks the stored size and matches the first 4 KiB against the declared content type.
Files are limited to 25 MiB and eleven accepted content types. The declared size is checked before an upload URL is issued; confirmation checks the actual size. Pending files cannot be attached to a message and do not appear in message output.
A message can claim up to ten uploaded files from the same thread. Each must be unclaimed. If any attachment is invalid, the entire message is rejected.
Events and notifications
Webhooks report seven event types: three for messages, two for threads, and two for surveys. Each payload includes the product and an idempotency key your receiver uses to deduplicate deliveries. Status-change events include the previous and new status names and categories. Thread creation is not an outbound webhook event. See Receive Support events.
Workspace notifications cover new threads, customer replies, and assignments. People configure them together under Support in notification settings. Support does not deliver replies to your end users; your product handles that. See Notifications.
Where Support sits
Support has no entry in Product App navigation. Its separate workspace App has four menu entries: Overview for the dashboard, Queue for the filtered inbox, Statuses for the status dictionary, and Agents for reply profiles. Open a thread from the queue to read its conversation.
The authenticated API exposes the same operations through support_* MCP tools, REST routes under /support, and the generated support namespace in @lepsto/sdk-app. There is no separate hand-written Support SDK. See Tools, SDK and errors.
The Public HTTP API provides sixteen routes for your backend using a product public key. It can open and read threads, post and read messages, read statuses, labels, and agent profiles, reserve, confirm, and delete files, read and answer published surveys, and read matching delivery rules. Assignment, status changes, profile edits, message corrections, and webhook management require the authenticated API.
Keep the public key on your backend. Your customer’s browser calls your backend, which calls Support. Support has no unauthenticated data routes and does not authenticate your end users.
Where to go next
- Answer your first thread: create and answer a ticket in seven steps.
- Threads and messages: filter conversations and catch up on messages.
- Surveys and delivery rules: collect feedback and decide where to show a survey.
- Public HTTP API: connect your backend with a product public key.