Update specific version of application

Update an existing specific version of an application with new artifacts and metadata. You can specify an updater type for artifact isolation when updating files for updaters that generate special files.

warning

You cannot change app_name, channel and version. app_name and version are used for correct searching.

Endpoint

POST /apps/update

Authentication

Header	Value
Authorization	Bearer <jwt_token>

Request Body

The request uses multipart/form-data format with the following fields:

Field	Type	Required	Description
file	file	❌	App binary file(s)
app_name	string	✅	Name of the application
version	string	✅	Version of the application
channel	string	❌	Channel (e.g., stable, beta)
publish	boolean	❌	Marks the version available for users
critical	boolean	❌	Marks the version as critical
platform	string	❌	Platform (e.g., linux, windows)
arch	string	❌	Architecture (e.g., amd64, arm64)
changelog	string	❌	Changelog in markdown format
updater	string	❌	Updater type for artifact isolation (manual, velopack, sparkle, squirrel_darwin, squirrel_windows, electron-builder, tauri)
signature	string	❌	Cryptographic signature (required for Tauri updater)

info

The updater parameter is useful when updating files for updaters that generate or ingest special files (like RELEASES for Squirrel Windows, *.yml for electron-builder, releases.{channel}.json for Velopack, or appcast.{channel}.xml for Sparkle). It ensures files are stored in isolated folders specific to that updater. For Sparkle, the edit flow re-ingests the appcast so metadata changes (including adding a platform/arch) carry into the materialized feed.

Example Requests

Single File Upload (Standard)

curl --location 'http://localhost:9000/apps/update' \
--header 'Authorization: Bearer <jwt_token>' \
--form 'data="{\"id\": \"653a6268f51dee6a99a3d88c\", \"app_name\": \"secondapp\", \"version\": \"0.0.2\", \"channel\": \"stable\", \"publish\": true, \"platform\": \"linux\", \"arch\": \"amd64\", \"changelog\": \"\"}"' \
--form 'file=@"/path_to_file/secondapp.deb"'

Update with Updater Parameter (Squirrel Windows)

curl --location 'http://localhost:9000/apps/update' \
--header 'Authorization: Bearer <jwt_token>' \
--form 'data="{\"id\": \"653a6268f51dee6a99a3d88c\", \"app_name\": \"secondapp\", \"version\": \"0.0.2\", \"channel\": \"stable\", \"publish\": true, \"platform\": \"windows\", \"arch\": \"amd64\", \"updater\": \"squirrel_windows\", \"changelog\": \"\"}"' \
--form 'file=@"/path_to_file/secondapp.exe"' \
--form 'file=@"/path_to_file/RELEASES"'

Update with Updater Parameter (Electron Builder)

curl --location 'http://localhost:9000/apps/update' \
--header 'Authorization: Bearer <jwt_token>' \
--form 'data="{\"id\": \"653a6268f51dee6a99a3d88c\", \"app_name\": \"secondapp\", \"version\": \"0.0.2\", \"channel\": \"stable\", \"publish\": true, \"platform\": \"windows\", \"arch\": \"amd64\", \"updater\": \"electron-builder\", \"changelog\": \"\"}"' \
--form 'file=@"/path_to_file/secondapp.exe"' \
--form 'file=@"/path_to_file/latest.yml"'

Multiple File Upload (Standard)

curl --location 'http://localhost:9000/apps/update' \
--header 'Authorization: Bearer <jwt_token>' \
--form 'data="{\"id\": \"653a6268f51dee6a99a3d88c\", \"app_name\": \"secondapp\", \"version\": \"0.0.2\", \"channel\": \"stable\", \"publish\": true, \"platform\": \"linux\", \"arch\": \"amd64\", \"changelog\": \"\"}"' \
--form 'file=@"/path_to_file/secondapp.deb"' \
--form 'file=@"/path_to_file/secondapp.rpm"'

Response

Success Response (200 OK)

{
  "updatedResult.Updated": true
}

Response Fields

Field	Type	Description
updatedResult.Updated	boolean	Indicates whether the version was successfully updated

Updater-Specific File Organization

When you specify an updater parameter, files are organized in isolated folders:

File Structure Examples

Standard Update (No Updater):

/secondapp/stable/linux/amd64/
├── secondapp-0.0.1.deb
└── secondapp-0.0.1.rpm

Squirrel Windows Update:

/squirrel_windows/secondapp/stable/windows/amd64/0.0.2/
├── secondapp.exe
└── RELEASES

Electron Builder Update:

/electron-builder/secondapp/stable/windows/amd64/0.0.2/
├── secondapp.exe
└── latest.yml

Supported Updater Types

Updater	Generated Files	Use Case	Special Requirements
manual	None	Standard FaynoSync uploads	None
velopack	releases.{channel}.json	Velopack cross-platform desktop apps	Requires channel, platform, and arch
sparkle	appcast.{channel}.xml	Native macOS apps using Sparkle	macOS only; upload the generate_appcast appcast + archives
squirrel_darwin	None	Squirrel macOS applications	None
squirrel_windows	RELEASES	Squirrel Windows applications	None
electron-builder	*.yml	Electron applications	None
tauri	None	Tauri applications with built-in updater	Requires signature field

Notes

• You can upload multiple files for different platforms/architectures in a single request
• The changelog field supports markdown formatting
• Critical versions are typically used for security updates or critical bug fixes
• Published versions are immediately available to end users
• Only the fields you provide will be updated - omitted fields remain unchanged
• Updater Parameter: Use the updater parameter when updating files for updaters that generate special files (RELEASES, *.yml)
• Artifact Isolation: Files updated with an updater parameter are stored in isolated folders to prevent conflicts
• File Organization: Generated files (RELEASES, *.yml) are properly organized when using updater-specific updates
• Signature Field: When using Tauri updater, the signature field is required for cryptographic verification of updates. This signature is generated by Tauri's build process and ensures update integrity and authenticity.
• Private Apps: a private app accepts only the manual, tauri and squirrel_darwin updaters. velopack, sparkle, electron-builder and squirrel_windows need a publicly served update feed, so they are rejected with 400: updater is not supported for private apps: <updater> requires a publicly served update feed; use manual, tauri or squirrel_darwin, or a public app
• Files cannot replace stored ones. Added files are checked before anything is written. A file whose platform, architecture and extension the version already has returns 409 with app with this name, version, platform, architecture and extension already exists, and the stored file is left untouched — to replace it, delete the artifact first and upload the new one. Two files of the request that would share a storage key or an extension return 400. A channel different from the version's returns 409 (the channel of a version cannot be changed); omitting channel keeps the version's own, and added files are stored in that channel's folder. Update feeds (RELEASES, *.yml, releases.{channel}.json, appcast*.xml) are exempt, since Velopack and Sparkle require the feed on every update and faynoSync regenerates it. .nupkg, .delta and .blockmap may repeat, but not under the storage key of a file the version already has — re-sending the same one returns 409. Previously a re-sent file overwrote the stored object while the version kept the old file's hashes