marchon/master-zapier-plan-draft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
master-zapier-plan-draft/research/zapier/raw/docs/integrations/news/single-page.md
George Lambert b4150c8250 Milestone 0: import zappier billing, Verae middleware, and Zapier research 
Compose-ready workspace: packages/zappier (rate card, portal, Stripe),
packages/verae-zapier-middleware (timestamp + NATS), packages/verae-zapier
(CLI app), vendor/zapier-platform, and research/zapier vendor corpus.

Gate 0 structure checks pass. Product code and research are not yet wired.
2026-09-09 02:37:36 -04:00

572 lines
24 KiB
Markdown
Raw Blame History

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zapier.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Platform News (Single Page)
> Recent changelogs and tips on a single page
## What's changed in v19.1.0
*Released: 2026-07-30*
This release improves auth template extraction and rendering: templates can now honor the real outbound request and integration-specific custom request properties when selecting credentials, non-auth request bodies are kept out of extracted templates, and `z.request(url, options)` calls are handled correctly during extraction. It also fixes the `appTester` TypeScript signature to accept request templates.
**cli**
None!
**core**
* Thread `targetRequest` through `renderAuthTemplate` so rendering can honor the real outbound request ([#1298](https://github.com/zapier/zapier-platform/pull/1298))
* Support `customRequestProperties` in the `renderAuthTemplate` bundle, letting integration middleware select the right credential during rendering ([#1322](https://github.com/zapier/zapier-platform/pull/1322))
* Drop non-auth request bodies from extracted auth templates ([#1323](https://github.com/zapier/zapier-platform/pull/1323))
* Preserve `z.request(url, options)` options in auth-template request stubs, and honor `customRequestProperties` during template extraction ([#1324](https://github.com/zapier/zapier-platform/pull/1324))
* Support request templates in the `appTester` type signature ([#1302](https://github.com/zapier/zapier-platform/pull/1302))
**schema**
None!
***
## What's changed in v19.0.0
*Released: 2026-05-18*
Version 19.0.0 is a **BREAKING CHANGE** release. Here is a brief breakdown of the main change (**❗ denotes a breaking change**):
**❗ The `zapier` binary has been removed**
The `zapier` command was deprecated in v18.0.0 in favor of `zapier-platform`. v19 completes that transition by removing the old binary entirely.
***
Apart from this major change, here are the detailed release notes for this release (**note that ❗ denotes a breaking change**):
**cli**
* ❗ Remove the `zapier` executable; the CLI now ships only `zapier-platform` ([#1299](https://github.com/zapier/zapier-platform/pull/1299))
**core**
None!
**schema**
None!
***
## New platform guardrails for safer integration versioning
*Effective: 2026-05-12*
**What's new**
The platform now automatically checks for breaking changes when you [promote](/integrations/manage/promote) a new integration version. If breaking changes are found and the version doesn't increment the major number, promotion is paused with a clear explanation of what was detected and which version number to use instead.
This helps you catch issues **before** they reach users — no more accidentally shipping a removal or auth change under a patch bump.
**What gets checked**
When you promote, the platform compares the new version against the current public version at the **schema level** — looking at the structure of your triggers, actions, searches, and authentication. The following schema-level breaking changes are detected automatically:
* **Removed triggers, actions, or searches** — a key present in the current public version is missing in the new version
* **Authentication type change** — the auth type (e.g., `oauth2`, `apiKey`, `session`) differs between versions
* **Trigger type change** — a trigger switched between polling and hook type
* **Removed searchOrCreate keys** — a searchOrCreate present in the current version is missing
* **Removed input field keys** — an input field key on an existing trigger/action was removed
* **Optional input field made required without a default** — an existing optional field is now required but has no default value
* **Authentication field changes** — removing an auth field, adding a new required auth field, or changing an auth field's type
* **Input field type changes** — changing the type of an input field (e.g., `string` → `list`)
* **Incompatible JSON field schema changes** — backward-incompatible changes to `json`-type input field schemas
If any of these are detected, you'll see a message explaining the specific changes found and the minimum major version required.
<Note>
These checks cover **schema-level** changes only. Some breaking changes happen outside the schema — for example, removing or renaming output field keys, changing the behavior of a perform function, or altering response structures. These are still your responsibility to catch. Review the full [versioning matrix](/integrations/manage/planning-changes) before promoting.
</Note>
**What this means for you**
* **If you're already following semver**, nothing changes. You're good.
* **If a promotion is paused**, read the message — it tells you exactly which changes triggered the check and what version number to use. Bump the major version and promote again.
* **If you need to phase out a trigger, action, or search without a major bump**, [hide it](/integrations/manage/versions#what-counts-as-a-breaking-change) instead of removing it. Hidden items continue to work for existing Zap workflows but are no longer available to new users.
For the full list of what gets detected and how to choose the right version number, see [Version numbering](/integrations/manage/versions#version-numbering).
***
## What's changed in v18.6.0
*Released: 2026-05-05*
This release adds two new commands that let you inspect and render the authentication request your app produces. They run your app's middleware (`beforeRequest`, `getAccessToken`, etc.) with placeholder credentials and capture the resulting auth request shape (headers, query params, and body) without making a real network call.
`zapier-platform invoke auth template` returns the static template (with `{{placeholders}}` for auth fields). `zapier-platform invoke auth render` substitutes real auth data from .env into that template and returns the final request.
**cli**
* 🎉 Add `invoke auth template` and `invoke auth render` commands ([#1282](https://github.com/zapier/zapier-platform/pull/1282))
**core**
* 🎉 Add `getAuthTemplate` and `renderAuthTemplate` Lambda commands ([#1282](https://github.com/zapier/zapier-platform/pull/1282))
**schema**
None!
***
## What's changed in v18.5.1
*Released: 2026-04-30*
This patch release improves the error message you get when an app definition fails to load, removes `platformData` from the bundle, and finishes the rename of the CLI binary from `zapier` to `zapier-platform` across docs and the `help` command.
We're renaming `zapier` to `zapier-platform` because the `zapier` binary name will be allocated to the [Zapier SDK](https://docs.zapier.com/sdk). The `zapier` binary still works in v18, but in the next major release (v19), we'll officially remove it — you'll need to use `zapier-platform` instead. If `zapier-platform` is too long to type, you can set up a shell alias like `alias zp=zapier-platform`.
**cli**
* 📜 Rename binary name from `zapier` to `zapier-platform` in docs, source, and `help` command ([#1291](https://github.com/zapier/zapier-platform/pull/1291), [#1292](https://github.com/zapier/zapier-platform/pull/1292), [#1293](https://github.com/zapier/zapier-platform/pull/1293))
**core**
* 🐛 Throw actionable error when app definition fails to load ([#1288](https://github.com/zapier/zapier-platform/pull/1288))
* 🐛 Remove `platformData` from bundle logging ([#1289](https://github.com/zapier/zapier-platform/pull/1289))
**schema**
None!
***
## What's changed in v18.5.0
*Released: 2026-04-16*
This release adds line item support to the `zapier-platform invoke` command and bumps `lodash` across all packages to address a security vulnerability.
[Line items](/integrations/build-cli/input-fields#line-items) are fields with a `children` property that represent structured, repeating data — like rows in a spreadsheet or items in an order. The `invoke` command now supports them in both interactive and non-interactive modes:
```bash theme={null}
**Non-interactive: pass line items as JSON**
zapier-platform invoke create order --non-interactive \
-i '{"name": "My Order", "line_items": [{"product_name": "Pens", "quantity": "12", "price": "1.50"}]}'
**Interactive: use the line item editing UI**
zapier-platform invoke create order -i '{"name": "My Order"}'
```
In interactive mode, a sub-menu lets you add, edit, and delete items with per-field editing and required field validation.
**cli**
* 🎉 Add line item support to `invoke` command with interactive editing UI ([#1272](https://github.com/zapier/zapier-platform/pull/1272))
* 🎉 Add `line-items` project template for `zapier-platform init` ([#1272](https://github.com/zapier/zapier-platform/pull/1272))
* 🐛 Fix `invoke` bugs: auto-detect auth ID for no-auth apps in remote mode, falsy value handling (`0`, `false`) causing infinite dropdown re-prompting, and more ([#1272](https://github.com/zapier/zapier-platform/pull/1272))
* 🔨 Bump `lodash` from 4.17.23 to 4.18.1 ([#1274](https://github.com/zapier/zapier-platform/pull/1274))
**core**
* 🔨 Bump `lodash` from 4.17.23 to 4.18.1 ([#1274](https://github.com/zapier/zapier-platform/pull/1274))
**schema**
* 🔨 Bump `lodash` from 4.17.23 to 4.18.1 ([#1274](https://github.com/zapier/zapier-platform/pull/1274))
***
## What's changed in v18.4.0
*Released: 2026-04-06*
This release introduces the new `json` input field type, improved `zapier versions` output, and a schema validation fix.
You can now accept structured JSON input from users with the new [`json` field type](/integrations/build-cli/input-fields#json-fields). Optionally provide a `schema` to validate and describe the expected shape:
```javascript theme={null}
{
key: 'product',
type: 'json',
label: 'Product',
helpText: 'Enter a JSON object',
schema: {
type: 'object',
properties: {
name: { type: 'string' },
price: { type: 'integer' },
},
required: ['name'],
},
}
```
We also fixed a bug where pushing code with [function-based dynamic dropdowns](/integrations/build-cli/dynamic-dropdowns#function-based-dynamic-dropdowns-perform) caused an unexpected validation error on the server. If you want to use function-based dynamic dropdowns, upgrade to 18.4.0 or later:
```javascript theme={null}
{
key: 'project_id',
label: 'Project',
type: 'string',
required: true,
choices: {
perform: async (z, bundle) => {
const response = await z.request('https://api.example.com/projects');
return {
results: response.data.map((project) => ({
id: project.id,
label: project.name,
})),
paging_token: null,
};
},
},
}
```
**cli**
* 💅 Clarify `zapier-platform versions` timestamps with separate "Created at" and "Updated at" columns ([#1275](https://github.com/zapier/zapier-platform/pull/1275))
**core**
* 🎉 Add JSON field type handling with schema-aware TypeScript inference ([#1273](https://github.com/zapier/zapier-platform/pull/1273))
**schema**
* 🎉 Add JSON input field type with optional `schema` property for structured data ([#1265](https://github.com/zapier/zapier-platform/pull/1265))
* 🎉 Validate `schema` property on JSON fields against JSON Schema meta-schema ([#1267](https://github.com/zapier/zapier-platform/pull/1267))
* 🐛 Fix oneOf ambiguity in FieldChoicesSchema that caused server-side validation errors for function-based dynamic dropdowns ([#1268](https://github.com/zapier/zapier-platform/pull/1268))
* 📜 Update `skipThrowForStatus` documentation to note 401 errors are not subject to the flag ([#1270](https://github.com/zapier/zapier-platform/pull/1270))
**misc**
* 🔨 Improve publish workflow with path filters and boilerplate build fixes ([#1264](https://github.com/zapier/zapier-platform/pull/1264), [#1266](https://github.com/zapier/zapier-platform/pull/1266))
***
## What's changed in v18.3.0
*Released: 2026-03-12*
Add support for function-based dynamic dropdowns
**cli**
* 🎉 Add support for function-based dynamic dropdown to the invoke command ([#1206](https://github.com/zapier/zapier-platform/pull/1206))
**core**
None!
**schema**
* 🎉 Add FieldDynamicChoicesSchema for function-based dynamic dropdowns ([#1206](https://github.com/zapier/zapier-platform/pull/1206))
***
## What's changed in v18.2.3
*Released: 2026-03-04*
Bug fixes for the CLI build command and pnpm compatibility.
**cli**
* 🐛 Surface package manager errors in `build` command ([#1254](https://github.com/zapier/zapier-platform/pull/1254))
**core**
* 🐛 Declare `zapier-platform-legacy-scripting-runner` as an optional peer dep to fix pnpm strict module resolution ([#1255](https://github.com/zapier/zapier-platform/pull/1255))
**schema**
None!
***
## What's changed in v18.2.2
*Released: 2026-02-26*
Improved error handling when loading the legacy-scripting-runner module in core. The runtime now logs a warning with the actual error message when the module is installed but fails to load, making it easier to diagnose issues like missing transitive dependencies.
**cli**
None!
**core**
* 🐛 Log a warning when `zapier-platform-legacy-scripting-runner` is installed but fails to load, instead of silently returning null ([#1247](https://github.com/zapier/zapier-platform/pull/1247))
**schema**
None!
**misc**
* 🔨 Fix publishing workflow to run on pushes to `main` ([#1243](https://github.com/zapier/zapier-platform/pull/1243))
* 🔨 Add non-interactive mode to bump script ([#1249](https://github.com/zapier/zapier-platform/pull/1249))
***
## User migrations must stay within the same major version
*Effective: 2026-02-26*
**Same-major-version migrations only**
* Migrations are only allowed when the **from** and **to** versions share the same major number (e.g. `1.0.0` → `1.0.1`, or `2.1.0` → `2.2.0`).
* Cross-major moves (e.g. `1.5.0` → `2.0.0`) are blocked in both the [Platform UI](https://zapier.com/app/developer) and via [`zapier-platform migrate`](https://github.com/zapier/zapier-platform/blob/main/packages/cli/docs/cli.md#migrate). This aligns with long-standing guidance; major releases include [breaking changes](/integrations/manage/planning-changes), so users should [update Zap workflows manually](https://help.zapier.com/hc/en-us/articles/18755649454989-App-versions-in-Zapier) or you should use [deprecation](/integrations/manage/versions#deprecating-versions) instead of migration.
* Details and workflow are in [Migrate users to a new version](/integrations/manage/migrate).
***
## What's changed in v18.2.1
*Released: 2026-02-23*
Resolved a bug in the CLI that caused the `build` command to fail when using a symlink-based package manager (like pnpm).
**cli**
* 🐛 `zapier-platform build` no longer raises `EEXIST` when using a symlink-based package manager ([#1244](https://github.com/zapier/zapier-platform/pull/1244))
**core**
None!
**schema**
None!
***
## Pushing unlabelled semantic versions must be sequential
*Effective: 2026-02-23*
**What changed**
These rules apply to **unlabelled** [semantic versions](/integrations/manage/versions#version-numbering) only (for example `1.2.3`). **[Labelled versions](/integrations/manage/labeled-versions)** (such as `1.2.3-beta` or `0.0.0-my-feature`) are not part of these checks.
When you push a new unlabelled version, the platform validates **two** things in addition to existing format checks.
**1. You cannot skip a required predecessor**
The API must see the right **previous** unlabelled release before it accepts the new one:
* **Patch bump** (`1.2.3`): the exact unlabelled `1.2.2` must already exist.
* **Minor bump** (`1.3.0`): at least one unlabelled `1.2.x` must exist.
* **Major bump** (`2.0.0` when coming from `1.x`): at least one unlabelled `1.x.x` must exist.
`1.0.0` is unchanged: there is no prior semver to require.
If the predecessor is missing, push fails with **403** and guidance like: *Version X requires Y to exist. Push version Y, then try again.*
**2. You cannot insert an “intermediate” version behind a newer line**
You also cannot push a version if a **newer** unlabelled version already exists in the segment that would make yours a backward insert:
* **`1.2.3`**: blocked if any unlabelled **`1.2.4` or higher** on the same `1.2.*` line already exists. Pushing **`1.3.0`** is still allowed when only `1.3.x` or `2.x.x` exists—those are not on the `1.2.*` patch line.
* **`1.3.0`**: blocked if any unlabelled **`1.4.x` or higher** on the same major (`1.*`) already exists. **`2.0.0`** is still allowed when only `2.x.x` exists.
* **`2.0.0`**: blocked if any unlabelled **`3.x.x` or higher** already exists.
If that applies, push fails with **403** and a message that an existing version would make this an intermediate release, which is not allowed.
**What this means for you**
* Plan **patch → patch → minor → major** (or the minimal chain your history needs) using **unlabelled** semver when you are ready to record real releases; use **labelled** snapshots while iterating.
* If you are stuck because old versions were removed, you may still use **[deprecation](/integrations/manage/versions#deprecating-versions)** and, when appropriate, **[delete a deprecated version](/integrations/manage/deprecate#deleting-deprecated-versions)** so your remaining unlabelled history matches what you want to push next.
***
## What's changed in v18.2.0
*Released: 2026-02-18*
The main change in this release is to support function-based choices in the `invoke` command, which will allow developers to test perform-based dynamic dropdowns.
**cli**
* 🎉 `zapier-platform invoke` now supports function-based choices ([#1237](https://github.com/zapier/zapier-platform/pull/1237))
**core**
* 🐛 If we attempt to stash a large response but it's bigger than the max limit, throw a descriptive error with the actual size and the limit ([#1238](https://github.com/zapier/zapier-platform/pull/1238))
* 🔨 Add an environment variable to allow suppressing cleaning up env vars ([#1242](https://github.com/zapier/zapier-platform/pull/1242))
**schema**
None!
**misc**
* 🔨 CI: Use `environment` to publish ([#1239](https://github.com/zapier/zapier-platform/pull/1239))
* 🔨 CI: Automate the boilerplate upload ([#1240](https://github.com/zapier/zapier-platform/pull/1240))
***
## What's changed in v18.1.1
*Released: 2026-01-29*
Main change introduced here is fixing missing HTTP error logs that were prematurely lost during a Lambda invocation.
**cli**
None!
**core**
* 🐛 Restore missing HTTP error logs ([#1227](https://github.com/zapier/zapier-platform/pull/1227))
**schema**
None!
**misc**
* 🔨 Bump lodash from 4.17.21 to 4.17.23 across the board ([#1228](https://github.com/zapier/zapier-platform/pull/1228), [#1229](https://github.com/zapier/zapier-platform/pull/1229), [#1230](https://github.com/zapier/zapier-platform/pull/1230), [#1231](https://github.com/zapier/zapier-platform/pull/1231), [#1233](https://github.com/zapier/zapier-platform/pull/1233), [#1234](https://github.com/zapier/zapier-platform/pull/1234), [#1235](https://github.com/zapier/zapier-platform/pull/1235))
***
## What's changed in v18.1.0
*Released: 2026-01-19*
The `zapier-platform invoke` command now supports a **remote mode**. By adding a `--remote` (`-r` for short) flag to the `invoke` command, such as:
```
zapier-platform invoke -r
```
... all invocations, including trigger/action invocation itself, input field definitions, and dynamic dropdown choices, will be executed remotely by the Zapier production environment. This means:
* The integration version you want to test has to be deployed first.
* The invocation results and the bundle payload passed to your integration code will match what you see in live production, which is great for testing.
* Remote mode is slower than local mode (without the `-r` flag).
Read more about the three different modes in the [`zapier-platform invoke --help`](https://github.com/zapier/zapier-platform/blob/main/packages/cli/docs/cli.md#invoke) documentation.
We also fixed an issue where the `build` and `test` commands were not correctly detecting package managers (like npm, yarn, pnpm, or bun) when your integration was part of a monorepo. Now, the CLI doesn't just look in the current directory for package manager indicators (like `package-lock.json` for npm), but also checks parent directories up to four levels up.
**cli**
* 🎉 Add `--remote` flag to `invoke` command ([#1220](https://github.com/zapier/zapier-platform/pull/1220))
* 🐛 Fix package manager detection in `build` and `test` commands to include parent directories ([#1225](https://github.com/zapier/zapier-platform/pull/1225))
**core**
None!
**schema**
None!
**misc**
* 📜 Improve internal development docs ([#1221](https://github.com/zapier/zapier-platform/pull/1221))
***
## What's changed in v18.0.7
*Released: 2026-01-07*
In response to the previous [Shai-Hulud incident](/integrations/build-cli/inc-547), we're changing our package publishing process to improve security. This release also includes a schema extension that allows `outputFields` to have a `sample` field. Lastly, we've refactored the `invoke` command to make upcoming enhancements easier.
**cli**
* 🔨 Refactor `invoke` command ([#1217](https://github.com/zapier/zapier-platform/pull/1217))
**core**
None!
**schema**
* 🎉 Allow a `sample` field to be provided for dynamic `outputFields` ([#1211](https://github.com/zapier/zapier-platform/pull/1211))
**misc**
* 🔨 Add publish job in CI ([#1212](https://github.com/zapier/zapier-platform/pull/1212), [#1223](https://github.com/zapier/zapier-platform/pull/1223))
***
## What's changed in v18.0.6
*Released: 2025-12-24*
The `zapier build` command was harcoded to use `npm install`. As alternate package managers gain adoption, the `zapier build` command will respect your app's package manager of choice.
It does this by checking the `packageManager` on the package.json file. If it is not defined, it will look for any relevant lock files. If still, none is defined, then will fallback to `npm`.
If you are familiar with using `zapier build` with the flag `--skip-npm-install`, this flag has been renamed to `--skip-dep-install`, but will continue to still work as an alias. In the future, we will remove the `--skip-npm-install` flag.
**cli**
* 💅 CLI build respects the integration's package manager ([#1216](https://github.com/zapier/zapier-platform/pull/1216))
**core**
None!
**schema**
None!
**misc**
* 🔨 Bump tmp from 0.2.4 to 0.2.5 ([#1207](https://github.com/zapier/zapier-platform/pull/1207))
* 🔨 Bump form-data from 4.0.4 to 4.0.5 ([#1208](https://github.com/zapier/zapier-platform/pull/1208))
***
## What's changed in v18.0.5
*Released: 2025-12-10*
<Info>
We're releasing v18.0.5, skipping comprimised versions v18.0.2, v18.0.3, and
v18.0.4, due to the prior [security
incident](/integrations/news/2025/npm-package-sec-inc).
</Info>
This release fixes a potential security vulnerability in the `build` command related to zip file decompression.
**cli**
* 🐛 Remove problematic decompress-tar dependency ([#1202](https://github.com/zapier/zapier-platform/pull/1202))
**core**
None!
**schema**
None!
**misc**
* 🔨 Switch to pnpm as package manager and task runner ([#1204](https://github.com/zapier/zapier-platform/pull/1204))
***
## Incident: Unauthorized Access to Zapier NPM Packages
*Released: 2025-11-24*
**Unauthorized Access to Zapier npm Packages**
**Note: No action is needed from Zapier users**, only from Zapier developers using one of the NPM package versions listed [on this page](/integrations/build-cli/inc-547). See that link for detailed mitigation recommendations.
All Zapier products are operating as expected and there is no indication of data loss or leak.
Please [see this link](https://status.zapier.com/incidents/01KAV9DDHMYT7R6MFHSB8C09E3#updates) for the most up-to-date information.
***
Looking for older news? [2026](/integrations/news/2026), [2025](/integrations/news/2025), and [old changelogs prior to v17](https://github.com/zapier/zapier-platform/tree/main/changelog)
Reference in a new issue View git blame Copy permalink