Quickstart

One prompt in.
One proven automation out.

You set up, hand off one sentence, and your agent runs the build loop — compose, lint, deploy, and call the live onboard_new_hire endpoint to prove it works. You watch as much as you want and step in at the checkpoints. Anyone can wrap one API as a tool; composing a governed Salesforce + Slack orchestration into one agent-callable tool is what only Workato makes possible.

Examples use one agent for concreteness, but the toolkit is open by design — no vendor-specific commands, nothing tied to one agent. Use it with Claude, Cursor, Windsurf, Codex, or any other. The toolkit is the constant; the agent is your choice.
you your agent your move
You set up
0 Install & verify you brew / scoop install · wk version ▸
# macOS — Homebrew
$ brew install workato-devs/tap/wk workato-devs/tap/recipe-lint
# Windows — Scoop
> scoop bucket add workato-devs https://github.com/workato-devs/scoop-bucket
> scoop install wk recipe-lint

# then, on either OS:
$ wk plugins install recipe-lint # register lint as a wk command
$ code --install-extension WorkatoLabs.recipe-visualizer # or cursor / windsurf
$ wk version && wk plugins list # verify — should list recipe-lint
No Workato workspace yet?

Start free — sign up for a Workato trial (a Developer Sandbox you authenticate to with --region trial in step 1).

You'll also need a Slack account you can test in and a Salesforce demo account. Make a channel called #team-welcome in Slack.

1 Authenticate you wk auth login --region trial ▸
$ wk auth login --region trial
# then, at the prompts:
# API token: paste your wrk_… token
# Environment: name it yourself (e.g. dev)
# Profile name [..]: enter to accept the suggestion, or type your own

$ wk auth status # verify connectivity
Where the token comes from

In Workato: Workspace admin → API clients. Create a Client Role with recipe / connection / lifecycle permissions, create an API Client with that role, and copy the token (starts with wrk, shown only once). Workato docs →

Set the region on the command, not at a prompt

wk auth login bare fails before you can paste your token — --region must be a flag. Use trial for the free sandbox; on a paid workspace use your data center (us, eu, jp, au, sg, il, cn).

2 Load the Workato Developer Skills you git clone …/recipe-skills.git ▸
$ git clone https://github.com/workato-devs/recipe-skills.git
# then load the base skill + Salesforce + Slack into your agent —
# loading differs by agent, so follow the repo's quick start:
# https://github.com/workato-devs/recipe-skills#quick-start
3 Create your project you wk init ▸
$ cd ~/github # or wherever you keep working projects
$ wk init
# prompts (both free-text you type):
# Project name: type a name (becomes the new directory)
# Auth profile: the profile from step 1 (run `wk auth list` if unsure)
$ cd <project-name>

Scaffold the project before you prompt, so the agent writes the recipe straight into a folder already mapped to your workspace — then deploying later is just wk push, no setup mid-flow.

4 Prompt your agent you → agent “Build a Workato automation that…” ▸
Build a Workato automation that takes a new hire's email, looks up
their User record in Salesforce, adds them to the #team-welcome Slack
channel, and posts a welcome message introducing them to the team.
Expose it through an API-endpoint trigger named onboard_new_hire, then
deploy it and call the live endpoint to confirm it works end to end.
The agent grounds before it writes

Guided by the skills, your agent confirms your exact connection names and checks your Salesforce objects/fields exist. It asks — it doesn't auto-detect your workspace, so answer with your real connection names.

Your agent builds — behind the scenes
5 Compose the recipe agent onboard_new_hire.recipe.json ▸

The agent writes onboard_new_hire.recipe.json — the multi-system flow in one file:

  • Salesforce — find the new hire's User record by email.
  • Slack — look them up, add them to #team-welcome, post the welcome message.
  • API-endpoint trigger — so the recipe can be called as a tool in step 8.
6 Lint-fix loop agent wk lint onboard_new_hire.recipe.json ▸
Why the agent runs this

Lint is a push gate — wk push refuses to deploy a recipe with errors. It's deterministic validation the agent can't fake (datapill syntax, schemas, control-flow), so the agent runs it and fixes until it's clean.

$ wk lint onboard_new_hire.recipe.json --skills-path ./recipe-skills/skills
# exit 0 = pass (warnings ok) 1 = lint errors 2 = invalid input
◉ Inspect the graph your move · optional preview icon · Cmd+Shift+V ▸
# Open onboard_new_hire.recipe.json, then any of:
# — click the preview icon, top-right of the editor (like Markdown preview)
Cmd+Shift+V # (Ctrl+Shift+V on Windows/Linux)
# — or right-click the file → "Visualize Recipe"

Render the recipe as an interactive graph — click a node for its inputs/outputs and jump to the source line. Watch as much or as little as you want; an agent-confident run can skip straight to deploy.

7 Push / deploy agent wk push ▸
Push creates your connections for you

Deploying goes through Workato's packaging APIs, so the platform creates any missing Salesforce and Slack connections (and folders) as part of importing the recipe — nothing to pre-build in the UI. You authorize them in the next step.

$ wk push --dry-run # preview what will be created
$ wk push # lints, then deploys
◉ Authorize connections your move recipe → Connections → sign in ▸

Authorize the connections the push just created: open the recipe in Workato, click the Connections tab, click each connection, and complete its sign-in in the right-hand panel.

That's your only hands-on bit here — once the connections are live, your agent takes over again to start the recipe and run the self-test.

8 Expose & self-test agent, alone wk recipes start · wk api … · curl ▸
The self-test, end to end

With its connections authorized, your agent starts the recipe, wraps it as a live API endpoint, mints a key (printed once at creation, so it captures it), and calls the endpoint over HTTP — terminal-only, no human, no UI.

$ wk recipes start <recipe-id> # connections are live now → start it (id from `wk status`)
$ wk api collections create --name "Onboarding API" --json # prints the collection's base URL
$ wk api endpoints create endpoint.json --collection <id> # bind POST /onboard → your recipe
$ wk api endpoints enable <endpoint-id>
$ wk api clients create --name "Onboarding" --collections <id>
$ wk api clients keys create <client-id> --name selftest --json # ← auth token, shown once
What's in endpoint.json

A four-field file the agent writes — name, method (POST), path (e.g. onboard), and flow_id (your recipe's ID).

Then the agent calls the live endpoint and reads the result:

$ curl -X POST <collection-base-url>/onboard \
    -H "API-TOKEN: <key>" -H "Content-Type: application/json" \
    -d '{"email":"newhire@example.com"}'
# → {"success":true,"slack_user_id":"U…","channel_id":"C…","message_ts":"…"}
Optional — also expose it as an MCP tool

The same collection can back an MCP server for chat-based agent clients: wk mcp servers create --name "Onboarding" --folder-id <id> --collection <id>. Reveal its token in the UI (AI Hub → MCP Servers → User access → Developer MCP Token), then claude mcp add onboarding <mcp-url>. The curl self-test already proved it works — MCP just makes it callable from chat clients.

◉ Confirm it in Slack your move open #team-welcome ▸

The success:true response is the machine's word for it — now see it for yourself. Open Slack and go to #team-welcome: your demo new hire should be a member, with a welcome message introducing them to the team. That's the Salesforce + Slack orchestration you built, running on one real call.

What success looks like

Your agent might take a different path each run — but a successful one ends the same way: it calls onboard_new_hire over HTTP, gets success:true back, and the demo new hire appears in #team-welcome. That's a real governed call against the deployed endpoint — see it, and the Salesforce + Slack orchestration you built is working.

▸ If your agent gets stuck · 5 tested redirects

The loop is forgiving — when the agent wanders, one line of redirection puts it back. These are the snags worth a ready-made nudge:

It built a "callable recipe" or "genie skill" instead of an endpoint

Redirect: "Rebuild it with an API-endpoint trigger." A recipe-function or genie skill can't be self-tested over plain HTTP, and genie skills force identity-based MCP auth that the CLI can't hand you a token for.

The Salesforce search fails with MALFORMED_QUERY / "field not present"

Redirect: "Keep sobject_name, limit, and field_list out of the action's extended_input_schema — list only the SObject's real fields." Those are reserved config keys; in the schema they leak into the SOQL WHERE clause.

It can't add the new hire to #team-welcome

Redirect: "Use invite_user_to_conversation (not …_to_channel), and resolve the channel to an ID via conversations.list — there's no add-by-name."

A Slack step returns nil / "no method 'where' for nil"

Redirect: "Native Slack adhoc output isn't body-wrapped — reference ["channels"], not ["body","channels"]." (Only the Workbot slack_bot adhoc uses a body wrapper.)

wk auth login 401s before you can paste the token

Redirect: "Pass --region as a flag (e.g. --region trial)" — it can't be answered at a prompt, and a token from one region 401s against another.

What to build next

You composed a governed, multi-system tool from one sentence. The same loop covers everything else — point your agent at another connector skill and go.

More connector skills
Asana, Gmail, Jira, Stripe, Datatable — each one build away.
Community examples
A gallery of real builds — share yours, borrow others'.
Why we build this way
The five principles behind the toolkit.
Bring us a wall you hit
Community feedback flows straight into the roadmap.