Manage a workspace

Use Workspace Settings to control who can access a workspace, which credentials can call its Actions, and who can change its subscription. This guide describes the behavior implemented in the checked-in Klu application. Your available plans and billing details come from the billing service configured for your deployment.

Before you begin

You must be an active workspace member to view workspace resources. Management operations require one of these roles:

  • The workspace owner is the user who created the workspace.
  • Members whose assigned permission is admin or owner can perform workspace-management operations.
  • Other members can use the workspace but cannot invite or remove members or manage billing.

The current Members page identifies the workspace owner with an Admin badge. It does not provide a control for assigning or changing roles. Treat role assignment as an administrative operation outside that page.

Manage members

Open Workspace Settings, then select Members.

Invite a member

  1. Select Invite.
  2. Enter the member's email address in Invite Teammates.
  3. Select Send Invite.

The invitation appears as Pending Invite until it is accepted. You can select Cancel invite to invalidate a pending invitation. The application rejects an invitation when that email already belongs to an active member of the workspace.

Remove a member

The workspace owner can select Remove next to another member and confirm the operation. The application prevents removal of the workspace owner.

Removal marks the membership as deleted and deactivates every workspace API key created by that member. Existing data remains associated with the workspace. Confirm that services owned by the departing member have moved to another key before removing them.

Manage developer API keys

Open Workspace Settings, then select API Keys. The page heading is Developer API Keys.

Create a key

  1. Select New API Key.
  2. Enter a descriptive name such as Production backend service.
  3. Select Create Key.
  4. Copy the displayed value and place it in your secret manager.

A key has access to all Apps and Actions in its workspace. The key list shows its creator and last-used state. Subsequent reads return a masked value, so capture the complete value from the creation dialog.

Create separate keys for separate services. This gives you a useful last-used signal and lets you revoke one integration without changing every client.

Revoke a key

Only the key's creator, the workspace owner, or Klu staff access can delete it in the checked-in application. Select the remove icon beside the key and confirm Delete API Key. The default key has no delete control in the current UI.

Revocation removes access immediately for clients using that value. Update and verify the dependent service before deleting its old key. A key owned by a removed member is shown as deactivated.

For request authentication and SDK setup, see Getting started with the API and SDKs.

Manage plans and billing

Workspace owners and members with an admin or owner permission can access billing operations. Requests from other members are rejected.

Open Workspace Settings and use the following pages:

  • Plans shows plans currently marked public by the configured billing service, plus the workspace's current plan when applicable. Use Subscribe, Upgrade, or Downgrade when the relevant control is available.
  • Billing shows Billing & Subscription, the current subscription period, payment details, and Manage Billing when a customer portal is available.

Plan names, prices, quotas, and availability are service data rather than constants in the application repository. Check the values shown in your workspace before approving a plan change. A checkout request is bound to the requesting user, workspace, plan, and a signed state that expires after 24 hours; restart checkout if an old session is rejected.

Control external and public Action access

Deploying an Action version assigns that version to an environment such as Preview, Staging, or Production. A deployment makes the Action available to authenticated API and SDK clients that select that environment. Deploying a new version to an environment replaces the version previously assigned there.

In Studio, open the publication dialog and use Deploy to Production, Deploy to Staging, or Deploy to Preview. After deployment, the dialog provides the Action GUID and generated API, SDK, cURL, and URL details supported by that Action.

Shareable public access has additional repository-enforced conditions. The Action and its App and workspace must be active, the selected Action version must be marked public, and that version must have an active deployment. A deployment alone does not satisfy every public-route check in the checked-in source. Verify the generated public URL in a signed-out browser before distributing it.

Public execution runs under a workspace-owned API key selected by the service. Treat a public Action as an unauthenticated entry point to the deployed prompt and its connected tools or Context. Review inputs, outputs, provider cost, connected data, and abuse controls before enabling it.

Administration checklist

Before a production launch or ownership change:

  • Confirm at least one active owner or administrator can manage the workspace and billing.
  • Give each production service its own named API key and record its owner.
  • Verify last-used signals before revoking keys.
  • Move credentials away from a member before removing that member.
  • Confirm the intended Action version in each environment.
  • Test authenticated API access and any public URL separately.
  • Read current plan and billing values from the workspace UI rather than relying on a saved price or quota.