Inth CLI
Manage Inth resources from the CLI
Use inth project for consent projects, inth code-audit for repository scans, inth inbox for findings, and inth vendor to list, read, approve, or ignore vendors that scans find. Resource writes take effect immediately. Use a saved sign-in or an API key accepted by the command, and check inth <command> --help for required scopes and flags.
Which command manages each resource?
| Command | Operation |
|---|---|
org list, org get <id>, org create | List, read, or create organizations |
region list | List project region IDs |
project list, project get <id> | Read projects, including consent settings |
project create --name <name> --region <id> | Create a project |
project update <id>, project delete <id> | Update or delete a project |
member list, member update <id> --role <role> | Read members or change a role |
member remove <id> | Remove a member |
invitation list, invitation create --email <email> --role <role> | Read pending invitations or send an invitation |
invitation cancel <id> | Cancel a pending invitation |
api-key list, api-key create --name <name> | List or create organization API keys |
api-key roll <id>, api-key delete <id> | Rotate or revoke a key |
billing | Read the organization's plan and credit balance |
feedback | Send a report about Inth to the Inth team |
code-audit repositories | List connected repositories |
code-audit scans | List scans, optionally with --repository and --status |
code-audit start --repository <id> | Start a scan of the repository's production branch |
code-audit request <preparation-id> --repository <id> | Check a delayed scan request |
code-audit get <id>, code-audit issues <id> | Read a scan or its report |
code-audit unlock <id> | Spend credits to unlock a report |
inbox list, inbox get <id> | Read findings, optionally filtering the list with --status |
inbox update <id> --status <status> --item-version <version> | Change a finding's status |
inbox github-issue <id> | Create a GitHub issue for a finding |
vendor list --project <project-id> [--state <state>], vendor get <vendor-id> --project <project-id> | List vendors seen on a project, or read one with its hosts and what loaded it |
vendor approve <vendor-id> --project <project-id>, vendor ignore <vendor-id> --project <project-id> | Approve or ignore a vendor seen on a project |
How do I list and configure consent projects?
List commands return one page. --limit defaults to 50 and accepts 1 through 100. Pass the returned cursor unchanged to --cursor for the next page.
Replace the example IDs with IDs returned by the API. Project writes accept --branding inth|c15t|none and a JSON array for --trusted-origins. Use --data '<JSON object>' instead of individual body options for nested fields or explicit null values.
How do I set up c15t in my app?
Run inth c15t from your app directory to choose an Inth project and set up c15t v3. Agent setup is recommended. The agent can adapt the integration to your app, move existing tracking behind consent, and verify the result in a browser. The picker selects agent setup first when an agent is installed. Otherwise, it selects a setup prompt to paste into your agent.
Scaffold detects the framework from package.json. Use --framework to choose it explicitly, and inth c15t --help to list supported frameworks. It writes the framework's quickstart files and installs its c15t packages from the stable v3 release line with the app's package manager. Next.js and React use c15t@3; the HTML script tag needs no package installation. Existing generated files must match, or setup stops without overwriting them. An existing .env stays intact; the next steps identify backend URL assignments to add or replace by hand. For an existing app with custom entry points or config, use an agent to adapt the integration.
Static HTML sites can scaffold without package.json. An existing index.html selects the HTML target, or use --framework html to create one. Existing pages stay intact, with instructions for adding only the missing script or preferences link. JSON plans expose file paths and existence flags.
Next.js scaffolding uses the active app or pages directory, including apps that keep these directories under src. An existing next.config.js, next.config.mjs, or next.config.ts stays intact. Follow the next steps to wrap its current config in withConsentManifest.
Next.js quickstart entry points do not import an app stylesheet or require an @ path alias. Astro autodetection selects static output. Use --framework astro to choose server output explicitly.
For Next.js Pages Router, scaffold reads a literal pageExtensions list from your config and uses its suffixes for existing entries and new consent API routes. Use agent setup for computed extension lists or page formats other than JavaScript and TypeScript.
Nuxt scaffolding uses the root app.vue for Nuxt 3 and app/app.vue for Nuxt 4. It also supports a literal srcDir inside the app. Scaffold preserves existing app components and config filenames, and gives instructions to add the consent components and c15t/vue module. Use agent setup for a computed source directory.
SvelteKit scaffolding requires stable SvelteKit 2.63+ or 3.x to match @c15t/svelte@3. Setup checks the installed Kit version first, then simple exact, caret, or tilde versions in package.json when Kit is not installed. If the range cannot be checked, install dependencies and retry. Upgrade and install older apps before scaffolding, or use agent setup to plan the upgrade. Setup preserves your existing Svelte config and package manifest.
For an existing .env, scaffold distinguishes new keys from assignments to replace. If the selected backend variable occurs more than once, the instructions ask you to keep one assignment with the selected backend URL. Existing file contents stay out of the output.
To create a hosted project, pass --name Website --region <region-id> instead of --project. Use inth region list to choose the region. Scaffold checks local files and asks for confirmation before creating a project. --dry-run previews the files without creating a project, writing files, or installing packages. --yes confirms file creation, and --skip-install leaves package installation to you. Windows always skips installation and prints the required packages. Use --resume to undo files from an interrupted scaffold before trying again.
Agent flags include --codex, --claude, --cursor, --grok, and --fx. The agent must be installed on your path, and agent sessions run in the terminal on macOS and Linux. Use prompt --json to export public setup inputs for another agent. Scaffold and prompt accept --json; interactive agent sessions do not.
How do I migrate a hosted c15t app from v2 to v3?
Run inth c15t codemods from your app directory. Each codemod rewrites one part of the v2 API. It needs no sign-in or Inth project, and changes only files in your app.
--list shows each codemod and whether it applies to the c15t version in package.json. Named codemods run in the order --list shows. --dry-run reports the changes without writing files. With --json, the result goes to stdout and progress lines go to stderr.
The codemods are ported from @c15t/cli@3.1.0 and cover hosted apps. Where an app uses offline or custom mode, they leave that code unchanged and add a TODO(c15t v3) comment. Other changes that need a decision also get a TODO(c15t v3) comment. Search for it after a run. To migrate offline mode, a self-hosted backend, or @c15t/node-sdk, use the codemods in @c15t/cli.
How do I start a Code Audit scan?
Run inth code-audit start --repository <id> with an ID returned by inth code-audit repositories. Supply a stable --request-id when a start may need a manual retry.
A scan start can return starting with a preparationId and repositoryId. Check those IDs with code-audit request until the state is started or failed. Each invocation checks once. Reuse the same --request-id when retrying a start.
How do I update an Inbox finding?
Run inth inbox get <id> to read the finding, then pass the returned version to inth inbox update using --item-version.
Inbox updates require the version from the latest read. Supported statuses are open, accepted, dismissed, and resolved. After a version conflict, read the item again before updating it.
How do I review a vendor?
inth vendor list --project <project-id> lists the vendors scans saw on a project, with their category, state, and vendor ID. Add --state active to see only vendors nobody has decided on yet. inth vendor get <vendor-id> --project <project-id> shows one vendor's hosts, when it was last seen, how it loaded, such as a script URL or a Google Tag Manager container, and its open Inbox finding.
Runtime findings also name the vendor. inth inbox get <id> shows its name, vendor ID, and project ID. Pass those IDs to vendor approve or vendor ignore.
Approving a vendor accepts its data sharing and resolves its runtime Inbox finding. Ignoring it dismisses the finding. Later scans keep the decision, and repeating a decision changes nothing. The output shows the vendor's new state and the Inbox finding the decision closed, or None when the vendor had no finding. With --json, read data.data.state and data.data.inboxItemId.
Listing and reading vendors needs projects.read, which API keys have. Vendor decisions need a person's sign-in with the vendors.write scope and an admin or owner role in the project's organization. Organization API keys cannot hold vendors.write. Sign-ins from earlier CLI versions lack the scope; run inth login again.
How do I send feedback about Inth?
Use inth feedback for unexpected failures, misleading docs, missing capabilities, or workarounds. Reports go to the Inth team immediately. Follow the user's permission to send feedback, and exclude credentials, personal data, customer payloads, and full transcripts. Do not report routine validation errors.
The API deduplicates identical reports from the same caller within a UTC day. Resending the same report returns the original reference with alreadySubmitted: true. Changed content or a new UTC day creates a new report. --request-id identifies the failed operation you are reporting.
Only --category and --message are required. Categories are bug, friction, docs_mismatch, feature_request, and performance. The optional --surface accepts api, mcp, cli, docs, sdk, dashboard, and other. When omitted, the API uses the transport, api, in the ticket subject. Optional flags include --expected, --actual, --reproduction, --request-id, --operation, --client-name, and --client-version.
You can instead pass the report fields with --data '<JSON object>'. Use camelCase property names such as requestId, clientName, and clientVersion. Do not combine --data with individual body flags. The server validates raw JSON bodies.
Feedback accepts a saved browser or agent sign-in, or an organization API key. It requires no product scope, organization role, or --organization selection and charges no credits. The limit is ten new reports per caller per UTC clock hour; same-day duplicate reports do not consume that quota. Feedback returns HTTP 429 errors immediately without waiting or retrying. Continue the original task if reporting fails.
Human output shows the ticket reference and whether it was already submitted. With --json, read data.data.reference and data.data.alreadySubmitted.
Which commands send messages, expose secrets, or spend credits?
Writes run without confirmation prompts. Invitations send email, key rotation replaces the old key, report unlocks spend credits and require an owner, and inbox github-issue creates a GitHub issue. Key creation and rotation print the new secret once; save it before closing the terminal. An unresolved GitHub issue send can return 409 and require server reconciliation before another attempt.