{"id":3378,"date":"2026-08-04T16:07:45","date_gmt":"2026-08-04T20:07:45","guid":{"rendered":"https:\/\/blog2wrkdev.wpenginepowered.com\/workato-labs-whats-new\/"},"modified":"2026-09-28T10:15:12","modified_gmt":"2026-09-28T14:15:12","slug":"workato-labs-whats-new","status":"publish","type":"post","link":"https:\/\/blog2workato.wpengine.com\/workato-labs-whats-new\/","title":{"rendered":"Workato Labs: What’s New"},"content":{"rendered":"\n

A translation of what shipped in the latest wk<\/code> and recipe-lint<\/code> releases (both cut August 1, 2026), and in Developer Skills (from June 28\u2013August 1).<\/p>\n\n\n\n

Each packaged repo auto-generates release notes from merged PR titles. This post maps changes back to what developers will actually notice.<\/p>\n\n\n\n

\n\n\n\n

wk<\/code> v1.0.3<\/h2>\n\n\n\n

Release Notes (GitHub)<\/em><\/a>
Compare: v1.0.2...v1.0.3<\/code><\/a><\/em><\/p>\n\n\n\n

wk lint<\/code> prints readable output by default now.<\/strong>
(#95<\/a>) wk<\/code> gained support for plugin-owned output renderers. A plugin can declare its own formatter for human-readable text. Paired with the matching change in recipe-lint<\/code> below, this fixes an issue with wk lint<\/code>‘s default (non- --json<\/code>) output, which previously printed the raw internal result as literal Go map syntax (map[level:warn message:...]<\/code>). This is the highest-traffic command in the toolkit, so it’s the biggest default-experience fix in this release.<\/p>\n\n\n\n

Recipe mutation failures no longer fail silently.<\/strong>
(#92<\/a>) The platform API returns HTTP 200 with success:false<\/code> in the body for certain refusals, and wk<\/code> was discarding that body. Concretely, this meant: deleting a running<\/em> recipe would report success, delete your local .recipe.json<\/code>, and leave the server recipe running untouched, creating a silent local\/server divergence. wk recipes start<\/code> on a recipe with activation errors would just poll blindly for the full 2-minute timeout with no indication why. Both behaviors are now fixed: refusals now surface as typed errors with exit code 2, local files are preserved on a refused delete, and start<\/code> reports the actual activation error immediately instead of timing out.<\/p>\n\n\n\n

wk recipes jobs get<\/code> stops hiding why a job failed.<\/strong>
(#93<\/a>, corrected in #96<\/a>) The --json<\/code> output only declared four fields per job step, so input<\/code>, output<\/code>, error<\/code>, and the full HTTP error body were silently dropped by Go’s JSON decoder. You’d see a failed step with no indication of why. Both are now surfaced, including the downstream HTTP response (status, body, headers).<\/p>\n\n\n\n

Setup got clearer: CLI-to-API permission scopes are now documented.<\/strong>
(#94<\/a>, closing labs#1<\/a>) This one addresses a real first-five-minutes blocker: a developer hit a confusing 401: Unauthorized<\/code> on wk auth login<\/code> with no way to know which API client permission level was actually required. The README now lists the baseline scopes wk<\/code> needs, and known-limitations.md<\/code> documents the complete mapping from CLI functionality to the underlying API permission groups, so a permissions error is now something you can look up instead of guess at.<\/p>\n\n\n\n

New wk folders update<\/code> \u2014 rename and move, plus wk folders list --projects<\/code>.<\/strong>
(#93<\/a>, closing #91<\/a> and #97<\/a>) wk folders update <id><\/code> takes --name<\/code> and --parent<\/code> independently or together, so this is both a rename command and the first way to move a folder without a copy\/delete round-trip:<\/p>\n\n\n\n

wk folders update 123 --name \"New name\"\nwk folders update 123 --parent 456\nwk folders update 123 --name \"New name\" --parent 456\n<\/code><\/pre>\n\n\n\n
It routes to PUT \/folders\/{id}<\/code> or PUT \/projects\/{id}<\/code> depending on whether the target is a plain folder or a top-level project (projects are always top-level and can’t be reparented \u2014 the command errors if you try). wk folders list --projects<\/code> lists projects directly via GET \/projects<\/code> instead of inferring them from a flagged folder list. Together this closes out CLI coverage of the Projects & folders permission group \u2014 previously both renaming and moving required the UI.<\/p>\n\n\n\n
Also in this release: a couple of Windows-only test fixes with no user-facing behavior change (#99<\/a>).<\/p>\n\n\n\n
\n\n\n\n
recipe-lint<\/code> v1.1.0<\/h2>\n\n\n\n
Release Notes (GitHub)<\/em><\/a>
Compare: v1.0.0...v1.1.0<\/code><\/a><\/em><\/p>\n\n\n\n
Lint output is human-readable by default now.<\/strong> 
(#27<\/a>, closing #26<\/a>) The other half of the wk<\/code> renderer change above: recipe-lint<\/code> now implements the plugin-owned renderer contract, so you get actual formatted diagnostics. This is the default output of the most-run command, so it’s the top-priority fix in this release.<\/p>\n\n\n\n
Trigger-level filters now get datapill lint coverage.<\/strong> 
(#28<\/a>) The trigger’s “only continue if…” condition (code.filter<\/code>) was invisible to the linter in every sense: not parsed, not walkable by custom rules, and its lhs<\/code> values got none of the existing datapill checks that an if-block’s conditions already get for free. A malformed filter condition (e.g. a stray formula-mode string) used to pass wk lint<\/code> with zero diagnostics. Now filter.{field}<\/code> is a resolvable path for custom rules, and filter conditions get the same datapill validation as if-blocks.<\/p>\n\n\n\n
RETURN_RESPONSE_SCHEMA_CONSISTENT<\/code>‘s own suggested fix was wrong.<\/strong> 
(#25<\/a>) Following this rule’s previous suggested fix verbatim produced a recipe that linted clean but the platform refused to activate, as Workato requires every non-optional declared response field to be populated within its own block. The old text didn’t say so. The suggested-fix text now names the \"optional\": true<\/code> requirements explicitly. <\/p>\n\n\n\n
\n\n\n\n
recipe-skills<\/code><\/h2>\n\n\n\n
Currently, no releases\/tags exist for this repo. It’s distributed as a rolling main branch. The changes below are everything merged since 2026-06-28 (recipe-lint<\/code>‘s prior tag<\/a>, used as the cutoff).<\/em><\/p>\n\n\n\n
Skills are now discoverable by any agent, not just Claude Code, and installable without cloning the repo at all.<\/strong> 
(#6<\/a>, closing #5<\/a>; extended by #17<\/a>) First, a root AGENTS.md<\/code> was added so any AGENTS.md-aware agent (i.e. Codex, Cursor, Devon) routes a request to the right connector skill; previously that auto-discovery only worked in Claude Code. Then #17 went further: the skills library now packages as an installable plugin in each agent’s own marketplace (Claude Code, Codex, Cursor), so you install once and get recipe skills in any project. No cloning the repo, no relying on AGENTS.md discovery at all.<\/p>\n\n\n\n
Recipe-skills docs now flag a control_type<\/code> gotcha neither the importer nor wk lint<\/code> is positioned to catch.<\/strong> 
(#10<\/a>) control_type<\/code> was documented as required on trigger-level schema fields, but not on result_schema_json<\/code>, py_eval<\/code> input\/output schemas, or declare_variable<\/code>\/declare_list<\/code> fields, even though the Workato UI needs it there too, to give its datapill mapping picker something to attach to. It’s a UI-rendering requirement, not a structural one, so a recipe missing it imports fine and lints clean (including --profile strict<\/code>). There was never a validation rule this could have violated. The docs now call it out explicitly, with new validation-checklist items in python-snippets.md<\/code> and variables-and-lists.md<\/code>.<\/p>\n\n\n\n
A cluster of doc-accuracy fixes<\/strong>, mostly small: corrected if\/else equality operand and return_result<\/code> empty-string scope (#11<\/a>); nested array-of-primitive fields documented as stringified rather than iterated (#13<\/a>); three install\/lint workflow bugs fixed in cli-guidance.md<\/code> (#7<\/a>); new Scheduler trigger documentation (#14<\/a>); invalid condition operands fixed so the api-endpoint template actually activates (#15<\/a>). One to highlight specifically: #16<\/a> documents the optional: true<\/code> requirement for unified return_response<\/code> schemas in the api-endpoint skill \u2014 the docs-side companion to the exact same non-optional-field gap that recipe-lint<\/code>‘s RETURN_RESPONSE_SCHEMA_CONSISTENT<\/code> fix (above) addresses on the lint side.<\/p>\n\n\n\n
\n\n\n\n
New Contributors This Cycle<\/h2>\n\n\n\n
Four people showed up in these repos for the first time this cycle  :<\/p>\n\n\n\n