Help desk integrations you write and host yourself.
A custom ticket action — issue the refund, update the vendor record, suspend the account — usually leaves a team with two options: a vendor connector nobody can change, or glue code that carries its own role checks, retries, and audit logging. Latch Workflow plugins are the third. Write the action in TypeScript or Go against the ticketing system API, and permissions, approval steps, and the audit trail come from the platform.
Four steps. One ticket.
When an operator opens a ticket — or a case, if you work in a regulated function — the plugin sees the ticket type, metadata, and current state. It decides which actions are relevant and hides the rest.
The operator sees the available actions inside the ticket. They choose one — like "issue refund" or "update vendor record" — and confirm the details.
The plugin sends the request to Stripe, your ERP, Slack, your own model, or any internal API. Role checks, approval steps, and permissions are enforced before the action fires. The request leaves from your network, not from a vendor cloud.
The response from the external system — success, failure, confirmation details — writes back to the ticket timeline automatically. The audit trail stays complete.
The integration runs inside your boundary
A hosted help desk can only reach your ERP by being given a route to it. That means a credential in a vendor console, an inbound firewall rule or a tunnel, and every request body — invoice numbers, account identifiers, payment references — crossing a network you do not run. Most security reviews stall right there, which is why so many internal systems never get connected at all.
Latch is self-hosted, and plugins run in the same deployment as the rest of it. The plugin process reads its credentials from your secret store and calls Stripe, the ERP, or the payment processor directly. Nothing about the call is proxied through a vendor cloud, so data residency is a property of where you installed the software rather than a contract clause. In an air-gapped install, the plugin only reaches what the network already allows.
The honest limit: this puts the operational burden on you. Someone has to run the deployment, rotate the secrets, and keep the plugin dependencies patched. A five-person team with no infrastructure practice may be better served by a hosted tool until the first system they need to connect is one they cannot expose to the internet.
Stop building approval and audit infrastructure into every integration
Without plugins, every new system connection means building custom code for role checks, approval steps, error handling, and audit logging. That is weeks of work per integration — work that compounds as the team adds more systems. Plugins move that infrastructure into Latch so the team writes the action logic once and gets permissions, approvals, and audit trails for free.
The same contract carries the model. An AI plugin that classifies incoming tickets or drafts a reply is registered the way a Stripe plugin is, so swapping a hosted API for an open-weights model on your own hardware is a configuration change. The developer documentation and SDKs cover the action contract, the webhook surface, and local testing.
For engineering teams choosing whether to build workflow automation infrastructure or adopt it, the platform teams and startups guide explains where Latch replaces custom approval, audit, and ticket lifecycle code.
Permissions carry over
Role checks and approval steps apply to every plugin action automatically. The team does not rebuild that logic for each system.
Every action is recorded
The request, the response, and any failures write back to the ticket timeline. No separate logging infrastructure needed.
Start with one. Add more later.
Connect Stripe this week. Add the ERP next month. Each plugin is independent — adding a new one does not require changes to the existing ones.
What teams connect first
Most teams start with one plugin for the system that creates the most manual work. These are the most common starting points.
A customer requests a refund above the auto-approve threshold. The operator reviews the ticket, a second reviewer approves, and the Stripe plugin processes the refund — all from one screen.
A vendor bank-detail change arrives. The plugin surfaces the "update vendor record" action only after the ticket passes the required review steps. The ERP credential never leaves your network.
After a ticket closes, a plugin posts the outcome to a Slack channel — so the team stays informed without checking the queue manually.
An internal tool handles account suspensions, entitlement changes, or config updates. A plugin wraps that API call with role checks and an audit trail — including tools that are only reachable from inside the corporate network.
Questions about how plugins work
Common questions about connecting external systems to Latch through plugins.
How hard is it to build a plugin?
The integration is small by design. A plugin lists the actions available for a ticket, then runs one when the operator chooses it. TypeScript and Go SDKs handle the contract, so most plugins are tens of lines of code, not hundreds.
Where does a plugin actually run?
Inside your deployment, alongside the rest of the install — on-prem, in your private cloud, or air-gapped. The plugin reads its credentials from your own secret store and calls the external system directly. No API key, request payload, or ticket field is routed through a vendor-hosted service on the way.
Do plugins replace existing integrations?
No. Plugins wrap the call to your external system with permissions, approval steps, and an audit trail. The external system stays where it is. The plugin adds the control layer around it.
What happens when a plugin fails?
Failure becomes part of the ticket history. The team can see that the action was tried, what came back, and why the expected result did not happen. Nothing is silently lost.
Can I connect systems that do not have a public API?
If the system has any programmatic interface — REST, GraphQL, gRPC, a CLI, or even a database — a plugin can wrap it. The SDK is flexible about transport, and because the plugin runs on your side of the firewall it can reach systems that are not exposed to the internet at all.
How do plugins interact with approval steps?
Approval steps and plugins work together. A plugin action can require approval before it runs — including two-person review. The approval gate sits between the operator choosing the action and the action actually executing.
Pick one external system and see how it connects
Bring the system your team uses most — Stripe, an ERP, Slack, an internal API — and follow how a plugin wraps it with approval steps and an audit trail, on your own infrastructure.