Publishing Extensions

Publishing an extension to NodePit puts it on the product catalog with its own product page, and hosts its KNIME update site so users can install it directly from KNIME. This applies to any KNIME extension — whether it was built with Node Generator or by hand.

Quick Start

1. Get your product ID, edit token, and SFTP credentials — see Prerequisites.
2. Build your extension's update site and upload it over SFTP — see Update site.
3. Set your product page's name, description, and other content via the REST API — see Product page.
4. Wait for NodePit to crawl and index your update site; your product page goes live once that's done — see Going live.

These steps can happen in any order except the last — do them all before waiting on step 4.

Prerequisites

Publishing is set up by NodePit staff, not self-service. Contact mail@nodepit.com to get:

• A product registered — this assigns your extension a product ID, the slug it's addressed by on nodepit.com and in the upload commands below. Your product page will live at https://nodepit.com/product/<product-id>, starting out hidden.
• A product edit token — authenticates updates to your product page's content and metadata.
• SFTP credentials — a username and password for uploading update site files.

Keep the edit token and SFTP password secret — anyone with either can overwrite your product page or update site.

Product page

Your product page (https://nodepit.com/product/<product-id>) is the landing page for your extension — it's what users see when they click through from a search result or the catalog, and where they find the update site URL to install it. It also shows up as a card on the product catalog itself; that card is built from just icon, name, description, and style.color1/color2, so those four are worth getting right even if you don't touch anything else.

Everything on your product page — content and metadata alike — is a field on a single REST endpoint: PATCH https://nodepit.com/api/products/<product-id>, authenticated with your product edit token as a bearer token. Send only the fields you're updating in each request. Object fields — currently just style — are replaced wholesale rather than merged: if you PATCH style with only color1, any previously set backgroundImageUrl or badgeColor is lost. Include every style sub-field you want to keep in each request.

Field	Purpose	Format
name	Product title	String
description	Tagline shown in listings and search	String
text	Full product page body	Markdown, see below
changelog	Version history — badge and release feed	Keep a Changelog, see below
license	License terms	Markdown, no required structure
faq	Frequently asked questions	Q&A, see below
contact	Legal/support contact shown on the page	Object — name and email required if set at all
style.color1 / color2	Card and header gradient, top-left to bottom-right	Hex colors
style.backgroundImageUrl	Overrides the gradient with an image	URL, optional — set to "" to remove
style.badgeColor	Badge color, falls back to color1 if unset	Hex color, optional — set to "" to remove
instructions	Extra post-install setup section, beyond the update site	Markdown, optional — set to "" to remove
icon	Product icon, same as set at registration	SVG markup string (or iconBase64 for a raster image); the page crops it into a circle, so keep the artwork centered

text is rendered as-is, with any headings becoming sidebar nav anchors. It supports the placeholder, substituted with the current KNIME release at render time.

changelog must follow Keep a Changelog exactly: one # Title; one ## [Version] - YYYY-MM-DD heading per release; ### Added/Changed/Deprecated/Removed/Fixed/Security/Info sub-headings (others still parse, just render without a badge); changes as - list items. HTML comments are stripped before parsing.

faq treats each ## Question heading as a question, with the markdown up to the next ## as its answer.

Multi-line fields (text, changelog, license, faq, instructions) are easiest to update by reading from a local markdown file rather than hand-escaping JSON. On macOS/Linux, jq builds the request body for you:

curl -X PATCH "https://nodepit.com/api/products/<product-id>" \
  -H "Authorization: Bearer <product-edit-token>" \
  -H "Content-Type: application/json" \
  --data "$(jq -n --rawfile changelog CHANGELOG.md '{changelog: $changelog}')"

On Windows, PowerShell's ConvertTo-Json does the same, and Invoke-RestMethod replaces curl:

$uri = "https://nodepit.com/api/products/<product-id>"
$headers = @{ Authorization = "Bearer <product-edit-token>" }
$body = @{ changelog = Get-Content -Raw CHANGELOG.md } | ConvertTo-Json

Invoke-RestMethod -Method Patch -Uri $uri -Headers $headers `
  -ContentType "application/json" -Body $body

Swap changelog/CHANGELOG.md for the field and file you're updating — e.g. text/PRODUCT.md, license/LICENSE.md, faq/FAQ.md. Short plain-string fields like name and description don't need this — inline them directly:

curl -X PATCH "https://nodepit.com/api/products/<product-id>" \
  -H "Authorization: Bearer <product-edit-token>" \
  -H "Content-Type: application/json" \
  --data '{"name": "...", "description": "..."}'

Update site

Build your extension's P2 update site — with Node Generator this is mvn clean verify from the generated project, producing a zip under p2/target/ and an unzipped copy at p2/target/repository. The update site is hosted over plain SFTP (there is no REST API for this part), so any SFTP client works — on Windows, WinSCP or the sftp.exe that ships with Windows 10 and later are both fine.

Connect to nodepit.com on port 2222 with your SFTP username and password, then, under update-site/:

1. Upload the zip itself as update-site/<label>.zip, overwriting any existing file.
2. Upload the contents of p2/target/repository into update-site/<label>/, overwriting existing files.

<label> becomes part of the published update site's URL, symlinked on the server, and is served at https://download.nodepit.com/<product-id>/<label> — the URL users add as a KNIME "Available Software Site". NodePit conventionally labels update sites by the KNIME release they target (e.g. 5.9), since a KNIME extension's compatibility is usually pinned to a KNIME version rather than its own release cadence — but a semantic version (e.g. 1.0.0) works too if that fits your extension better.

Example workflows and assets

Your SFTP account has folders for images or other static files (assets/) and example KNIME workflows (workflows/) to reference from your product page. Upload into them the same way you'd upload the update site — same SFTP connection, different folder.

Files show up at https://download.nodepit.com/workflows/<product-id>/<path> and https://download.nodepit.com/assets/<product-id>/<path> respectively. Link to them directly from your text, faq, changelog, or instructions markdown — e.g. ![Example workflow](https://download.nodepit.com/assets/<product-id>/screenshot.png). There's no automatic path rewriting, so links must be absolute.

Automating with Node Generator

If your extension is built with Node Generator, pass --nodepit-product <product-id> to have it generate a CI pipeline that runs both uploads automatically on release. See the CLI Reference for the full set of publishing flags and the CI/CD secrets they require.

Going live

Uploading doesn't make your extension appear in the Node Catalog or on your product page right away. NodePit still needs to set up crawling for your update site so its nodes get indexed — this is a manual step done by NodePit staff after your upload. Your product page stays hidden until this indexing has settled, at which point NodePit enables it.

It's worth checking your upload actually worked before then: visit https://nodepit.com/product/<product-id> to see the (still-hidden but reachable) product page, and https://download.nodepit.com/<product-id>/<label> to confirm the update site is being served. A PATCH request to /api/products/<product-id> returns HTTP 2xx on success, so a non-2xx response there is worth investigating too.