Developer portal

The developer portal is where you manage the Kits your workspace owns. It lives in the workspace admin area under Developer and is available to admins of the Kit’s owner workspace. Everything you can do there is also available to the CLI through the developer API.

Create a Kit

Upload a manifest to create a Kit. A new Kit starts private. Before anything is stored, the portal validates the manifest: schema, slug ownership, domain coverage and, for an existing Kit, the difference to your latest published version. Problems block the upload; warnings (for example a host that still needs a verified domain before the Kit can be unlisted) do not.

Versions

Every upload registers one version of the Kit.

• A version is a draft until you publish it. Drafts are not installable and can be deleted.
• Publishing makes the version installable and applies the distribution its manifest asks for. For unlisted, every endpoint host needs a verified domain (see below).
• A version is immutable once registered. Uploading the same version number with a different manifest is rejected with 409; bump the version instead.
• The portal shows each version’s number, whether it is published, and the hashes of its manifest and of its consent document. The consent hash is what installers and admins approve (see Distribution and installs).

Verified domains

Ketvia calls the endpoint URLs of your manifest (tools, events, interactivity, commands) and sends members back to your OAuth redirect URLs. To keep a Kit from pointing at hosts it does not control:

• Every endpoint URL host of an unlisted Kit must be on a verified domain or one of its subdomains.
• A domain proves one Kit: the first Kit to verify a domain keeps it.
• Private Kits in the owner workspace may skip verification.

Add a domain on the Kit’s page and choose one of two proofs:

Method	What you publish
DNS	A TXT record on the domain with the value ketvia-kit-verification=<token>
Well-known	A file at https://<domain>/.well-known/ketvia-kit.json containing {"kitId": "<kit id>", "token": "<token>"}

The portal shows the exact record or file for your Kit. Choose Verify once it is live. A failed check is not an error: the result tells you whether the record was not found, did not match, the host was unreachable or the domain already belongs to another Kit, and you can try again after DNS has propagated. The Kit page also lists the hosts of your latest version that no verified domain covers yet.

Secrets

Secret	Format	Used for	Rotation
Client secret	kcs_	The kit.access code exchange	Rotating keeps the previous secret valid for a 24 hour overlap
Signing secret	kss_	Verifying requests Ketvia sends to you	Rotating keeps the previous generation valid for 7 days, so both sign during that window

Secrets are shown once, by the call that creates or rotates them. The portal afterwards shows metadata only (creation time, generation, and while a rotation overlaps, when the previous generation expires). While two signing secrets are valid, Ketvia sends both v1= values in Ketvia-Signature; see signatures in the SDK for how to verify with two secrets.

Install link

Unlisted Kits are installed through an install link. Creating and using it is described in Distribution and installs.

Developer tokens

A developer token (kdev_…) lets the CLI act for you.

• It is shown once, when you create it. Give it a name and, optionally, a lifetime.
• It acts as its member in its own workspace and only on the developer API (/api/v1/dev). It cannot call the Web API and never reaches another workspace.
• It expires after 90 days by default (at most 365 days).
• You can have at most 10 active tokens per member.
• You can revoke a token at any time. The list shows each token’s name, creation, expiry, last use and revocation.

Store a developer token like a password. Prefer one token per machine or CI job so you can revoke them separately.

Delivery and error log

Each Kit has a log viewer with the most recent entries first and cursor paging. An entry has a time, a source, a level (info or error), an event name, and where relevant the installation, a status, an error code, a duration, an HTTP status and an attempt number.

Source	What it shows
tool_call	Assistant tool executions of the Kit’s installations
audit	Kit audit events such as installs
delivery	Reserved for the events delivery log; not live yet

Filter by source and by level. The response lists which sources are live. The same log is available from the CLI with ketvia kits logs.

Security

Secrets are never logged. Tokens, client secrets and install links are stored as hashes; signing secrets are stored encrypted with AES-256-GCM and decrypted only to sign a request. A lost secret is replaced, never recovered.