Ticketing API and SDK
Add a custom action without rebuilding the ticketing system.
A transaction needs reprocessing. Your payment service owns the operation; the ticket owns the request, review and returned result. A Latch action provider connects them.
Write discovery and execution logic in TypeScript or Go. Configure the action gate in Latch, test the downstream failure paths, and keep the integration separate from application changes.
Action provider lifecycle
1. Discover
Receive ticket and user context. Return the available actions and the form schema needed to request one.
2. Request and review
Latch checks permissions and the configured approval requirement. Maker-checker prevents the action requester from approving or executing that request.
3. Execute
Execution is separate from approval. The provider receives the action identifier, saved form data and current ticket context after platform checks.
4. Return and reconcile
Return success or failure, a message and supported effects. Reconcile uncertain outcomes with the downstream system before another attempt.
Contract example
Return the result the operator needs to inspect.
This illustrative execution response uses the supported comment effect. The synthetic reference explains what happened in the downstream service. It is a contract fragment, not a complete provider or proof of a real payment operation.
Your service still needs authenticated requests, input validation, credential handling and an idempotent downstream operation. Validate the full workflow in a test environment before using it for sensitive work.
Illustrative execute response · synthetic data
{
"success": true,
"message": "Downstream request accepted. Reference: demo-4821.",
"effects": {
"add_comment": {
"content": "Synthetic example: reprocess accepted as demo-4821.",
"is_public": false
}
}
}Configure first
Queues, permissions and approval settings belong in the configured workflow.
Approval mechanics →Extend the action
A provider offers reprocessing and returns its result without adding a payment-specific endpoint to the core.
Plugins versus core changes →Assess source changes
Confirm Enterprise licence terms, upgrade ownership and the exact application change you need.
Source access and licensing →Check the authority and network boundary.
A private deployment does not make every internal destination reachable. Review provider endpoints and credentials with the deployment security controls.
An AI or MCP credential needs a defined scope. See what an agent token can reach, then test the action with an authorized user, an unauthorized user and the action requester.
Where the extension boundary sits
Bring one downstream operation and the decision that must precede it.
What languages do the action provider SDKs support?
TypeScript and Go. An action provider implements discovery and execution. The SDKs help with the contract; your team owns the downstream integration and its operating controls.
When should we write a plugin rather than modify Latch?
Use a plugin for a custom external action and configuration for permissions and approval settings. Assess Enterprise source access when the change belongs in the application, including maintenance across upgrades.
What can a plugin change on the ticket?
The current TypeScript execution contract supports adding a comment and changing ticket status. A downstream result can also be returned as response data. Historical data-write examples are not a current ticket-field API.
Can a plugin call any private URL?
No. Provider endpoints must pass the network policy. Loopback, metadata and private control-plane destinations are denied. A permitted private endpoint requires an operator-controlled mapping, which does not override those exclusions.
How should we handle a timeout?
A timeout can leave the external outcome uncertain. Keep a downstream operation reference, inspect its actual state and reconcile it before another attempt. Executing and uncertain requests remain blocked until reconciliation.
Can we inspect and adapt the application source?
Source code is available on Enterprise under a commercial source licence. Review the agreement for the changes and use you need before committing to an application fork.
Evaluate one custom action
Bring the downstream API, its failure behavior and the approval requirement. Review the plugin path and whether a source change is needed.