Deploy workflow bundles to Libretto Cloud, then use the failure emails and debug tools when runs break.
https://api.libretto.sh. Issue an API key, then add it to your project .env file:1LIBRETTO_API_KEY=<issued-api-key>
cloud deploy uploads one package directory at a time. That directory must contain:package.jsonindex.ts inside the directory you pass to deploy.1234567my-automations/ ├── package.json ├── index.ts └── src/ └── workflows/ ├── check-eligibility.ts └── submit-prior-auth.ts
workflow(...). Then index.ts should export the workflows you want Libretto Cloud to discover:12export { default as checkEligibility } from "./src/workflows/check-eligibility"; export { default as submitPriorAuth } from "./src/workflows/submit-prior-auth";
workflow("...") call inside the file, not the filename or the export alias from index.ts.cloud deploy against that package directory instead of the monorepo root.package.json.--entry-point is the file inside that package directory that Libretto should use for workflow discovery.1npx libretto cloud deploy my-automations --entry-point src/workflows/check-eligibility.ts
my-automations is the package directorysrc/workflows/check-eligibility.ts is the entry file relative to my-automationscloud deploy to upload a workflow bundle to Libretto Cloud:12cd my-automations npx libretto cloud deploy .
. to contain package.json./index.ts to be the deploy entry pointindex.ts to export the workflows that should be deployeddeploy is the source directory to package and upload. It is not the path to a workflow file.--entry-point relative to that directory:123npx libretto cloud deploy my-automations \ --description "payer portal workflows" \ --entry-point src/workflows/check-eligibility.ts
--auto-repair when failed jobs from this deployment should route to the autofix agent instead of the readonly debug agent.123456789101112131415161718192021// src/workflows/check-eligibility.ts import { workflow } from "libretto"; import { z } from "zod"; export default workflow( "check-eligibility", { input: z.object({ memberId: z.string(), }), output: z.object({ status: z.string(), }), startUrl: "https://example.com/eligibility", }, async ({ page }, input) => { return { status: "eligible", }; }, );
workflow: "check-eligibility". The params object must match the workflow input schema:123npx libretto cloud jobs create check-eligibility \ --params '{"memberId":"12345"}' \ --timeout-seconds 300
job_id immediately. The equivalent API request is:123456789101112curl -X POST "https://api.libretto.sh/v1/jobs/create" \ -H "x-api-key: $LIBRETTO_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "json": { "workflow": "check-eligibility", "params": { "memberId": "12345" }, "timeout_seconds": 300 } }'
12345678curl -X POST "https://api.libretto.sh/v1/jobs/get" \ -H "x-api-key: $LIBRETTO_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "json": { "id": "<job-id>" } }'
workflow value must match the workflow name declared in code and discovered during deploy, not the deployment id, filename, or export alias.cloud schedules create for recurring runs. The cron expression is standard 5-field cron, and the timezone defaults to UTC:1234npx libretto cloud schedules create check-eligibility \ --cron "0 14 * * 1-5" \ --timezone America/Los_Angeles \ --params '{"memberId":"12345"}'
--params-file instead of --params when the workflow input is too large to keep inline.