Settings Reference

Open Settings

1. Open Settings from the app sidebar.
2. Select the section for the setting you need.

Workspace People & Access is in Admin → People & Access, and role definitions are in Admin → Permissions. The current Workspace settings form covers appearance; it is not the member-management screen.

Company sign-in

Company sign-in lets staff sign in with your company's own identity provider. It is on the Pro+ plan. Only a workspace owner or admin can open Admin → Company sign-in.

Saving a connection does not turn sign-in on. Go live, on the Sign-in card, does. Before it works:

• Plan: the workspace is on Pro+.
• Connection: your provider is connected.
• Domain: at least one domain is proved.
• Open: iKanban has opened going live. Until then the card says "Going live is not open yet".

To go live, select Go live. A new provider can take about two minutes before its first sign-in works. A domain that you prove after going live does not route to your provider until you select Update domains. The audit log shows sso.connection_live and sso.connection_domains_updated.

To take it offline, select Take offline. No one can start a new sign-in through your provider. Nothing else changes: email, Google and GitHub sign-in keep working for everyone, and no one leaves the workspace. A person who only ever used company sign-in signs in with email or Google at the same address. A person already signed in can stay signed in until their session ends. The audit log shows sso.connection_offline. Removing the connection also takes it offline. A domain you remove, or whose proof lapses, stops going to your provider at once; when no proved domain is left, the connection goes offline.

If another admin changes company sign-in at the same moment, iKanban asks you to try again a moment later. If a step fails, iKanban puts back what it changed, and the connection stays as it was.

When the connection is live, iKanban applies these rules at each sign-in:

• Your connection only. Besides email, Google and GitHub, a sign-in through any provider other than your connection is refused.
• Proved domains only. The provider's email must be in a domain that your workspace has proved. A domain whose proof has lapsed counts as not proved, for new sign-ins and for people who already joined. An address with a trailing dot, or in a subdomain you have not proved, is refused. Uppercase letters are read as lowercase.
• Verified email. The provider must say that the email is verified. For an OIDC provider, this is the email_verified claim. For a SAML provider, send an attribute named email_verified with the value true. If the attribute is missing, iKanban reads it as not verified and refuses the sign-in, so add it before your staff sign in.
• The first sign-in joins as a member. An owner or admin raises a role. A person whose address already has an iKanban account confirms first, whether or not they belong to a workspace: iKanban asks them to sign in the old way once, in the same browser, within ten minutes. Then they click Connect on the screen that names your workspace and their account. They join as a member, or keep their role and seat if they are already in your workspace. Their other workspaces stay as they are, and their old sign-in keeps working. The audit log shows this as sso.link_confirmed. Signing in to a different account is refused and is in the audit log as sso.link_refused. The desktop app and the CLI cannot do this step: the person does it once in a browser. An address with only an invitation elsewhere and no account has nothing to confirm with, so that person is refused and asks their admin.
• Seats follow. The new member takes a seat, and a seat you pay for is billed. A pending invitation also holds a seat. If no seat is free, the person sees a line that tells them to ask an owner or admin.
• Removed stays removed. A person you removed or suspended cannot join again by signing in. A company sign-in counts only while the person holds a seat in your workspace: after a removal or a suspension it opens nothing, not even their other workspaces, and it cannot create API keys. A key they already made stays theirs. Their other sign-in keeps working, because company sign-in does not block another way in. Add them again from Admin → People.
• Pro+ only. If your plan no longer includes company sign-in, no new person can join through it.
• No iKanban admin access. A sign-in through a company provider never reaches iKanban's own Superadmin area.

Each refused sign-in is in your audit log, with its reason. The log does not hold the address that the provider sent. Team membership does not come with the first sign-in: add the person to a team from Admin → People.

To prove a domain:

1. Add your company's email domain under Domains.
2. Create the TXT record that the page shows, at your DNS host.
3. Select Check DNS. A new record can take some time to appear.

Only one workspace can prove a domain. Keep the TXT record in place: iKanban checks it once a day. After seven days of failed checks the proof lapses, the page shows this, and any workspace can then prove the domain. Removing a connection keeps your proved domains. An OIDC client secret goes only to the identity service, and iKanban does not store it. A change to an OIDC connection needs the secret again.

How staff sign in when the connection is live:

• Web and desktop app: select Sign in with your company on the sign-in page, and type your work email. The desktop app continues in your browser. The link stays hidden until a connection is live.
• CLI and MCP: these use an API key, not a sign-in, so nothing changes for them.
• Who goes to the provider: only an email whose domain your workspace has proved, on the Pro+ plan, with the connection live and the workspace not disabled. Every other email returns to the normal sign-in page. The domain must match exactly: sub.example.com needs its own proof. A proof that has lapsed counts as no proof. A domain can have at most 40 characters, because the identity service allows no more.
• What others can see: anyone who types an email at your domain sees that it goes to a company sign-in page.
• How often: each network address can check 20 emails at once, and then one every 6 seconds. Past that, the page asks you to try again.
• A failed sign-in: iKanban shows its own message and asks you to try again, and then to ask your IT admin. It never shows the provider's error text.

API Keys

1. Open Settings → API Keys.
2. Select Create API Key, enter a name, choose the Area (All of iKanban or Security only), and choose whether to make it read-only. A read-only key can read data through the API and MCP but cannot create or update anything.
3. Create the key, copy it from the reveal panel, and store it in a secret manager before closing the panel.
4. Delete a key from the same page to revoke it.

Treat a key like a password. It represents its owner on supported agent routes. It does not grant access to browser-session-only routes such as key management, admin, billing, invitations, membership/role changes, sharing, or destructive deletes.

Some agent-facing REST routes accept vk_ keys. The API applies a deny-list, so this does not make every /api route available. REST and MCP both enforce the key's limits: Read only blocks every create and update, and Security only keeps the key in the Security area. The key list shows each limit as a badge.

A Security only key can read and file security findings, scans and fix tasks, and nothing else. Give one to a scanner or a CI job. See Team Security for the MCP tools and REST routes it can use.

On the same page, MCP access controls whether API keys can connect through MCP. The optional allowed-client list uses exact client names; an empty list allows any client. Changes can take up to five minutes to apply. Turning MCP off does not change REST access.

MCP Servers

1. Open Settings → MCP Servers.
2. Review the server URL and capabilities shown by the app.
3. Register the MCP server in your client using Streamable HTTP and a bearer key.
4. Store the key in the client’s secret facility, not in shared project files.
5. Confirm the connection with a read operation and inspect the result.

See MCP Usage for a client setup example. For allowed REST operations and session-only exclusions, see Setup and Access.

Workspace access and roles

Use Admin → People & Access to invite and review workspace members. Use Admin → Permissions for the workspace and team permission tables. See Members and Roles before changing access.

The API/MCP role tokens and the labels offered by each UI are not interchangeable. The role guide lists each surface separately.

Who can see and change billing

Any current member of a workspace can see its plan and invoice amounts. Only an owner or admin can open an invoice document, start a checkout, open the Stripe portal, change the plan or cancel it. A member who tries gets "Only a workspace owner or admin can change billing". Someone outside the workspace gets "Workspace not found". An owner or admin changes a member's role in Admin → People.