Manage a workspace and projects

An Anectico organization is the team and billing boundary. Projects separate application data inside that organization. Choose a project before investigating or configuring anything; the current project in the header controls most dashboard queries.

Create and choose projects

Open Settings → Projects to create a project with a stable name and slug. Use separate projects when data needs a real access or lifecycle boundary. Use the environment field within one project for production, staging, and development when the same application should remain searchable as one system.

Project controls follow the signed-in principal’s exact permissions. projects:read returns the project list and any single project’s record, and is available to every role, which is what keeps the header selector and Settings populated; projects:write additionally exposes create and edit actions, while projects:delete separately exposes deletion. Without either write capability, Settings keeps the project list visible in a clearly read-only state and the header does not offer a creation dialog. An API key with no projects:read cannot list projects at all — give an ingestion-only key its project at mint time instead. A newly provisioned organization with projects:write can still create its first project from the header when its project list is empty.

The active-project selector stays in the dashboard header on desktop, tablet, and mobile. On a phone, the trigger is narrower and truncates long names, but opening it still shows the complete project list. After creating a project:

1. select it in the dashboard header;
2. create or scope an application key with the required telemetry permissions;
3. configure every participating SDK or collector with that key; and
4. send a test signal before rolling out broadly.

An organization must keep at least one project. Deleting a project is destructive; verify which SDKs, alerts, API keys, dashboards, and automations refer to it first.

Project-scoped credentials are pinned to their signed project for project reads, updates, deletion, and project configuration. Passing a different project_id cannot widen access. Exact project lookups also return the same not-found response for a missing project and a project outside the credential’s organization, so callers cannot use the endpoint to discover another tenant’s IDs.

Invite and administer members

Open Settings → Team to review everyone who can access the current organization and confirm each person’s role. The signed-in account is marked You, which helps catch an unexpected organization or role before changing configuration. Owners and admins can invite a teammate from this page by entering the person’s email and choosing Admin, Member, Developer, or Viewer. Anectico emails a single-use acceptance link to that exact address and shows the invitation as pending until it is accepted or revoked.

The invitee signs in with the invited email before accepting. Acceptance switches that browser to the shared organization and clears cached data from the invitee’s previous personal workspace; the personal workspace itself is not deleted or merged. The same invitation operations are available through the Anectico CLI:

anectico invitations create [email protected] --role ROLE_MEMBER
anectico invitations list
anectico members list
anectico members set-role <user-id> ROLE_ADMIN
anectico members remove <user-id> --yes

An emailed invitation link resumes after you sign in. Anectico keeps the return path in an HttpOnly, same-origin cookie for the login round trip and removes the invitation token from the address bar once the acceptance page loads.

Only grant an admin role to people who need organization configuration or destructive capabilities. Removing a member does not rotate credentials they created; review and revoke unnecessary API keys separately.

Current organization roles are Owner, Admin, Member, Developer, and Viewer. Owners and admins receive organization configuration and destructive permissions. Members and developers receive the collaborative/operator surface, including self-service API-key management. Viewer is a read-only security boundary: viewers can inspect telemetry, dashboards, settings, and usage but cannot ingest, acknowledge, respond, edit, create, revoke, or delete product state. The Team page requires confirmation before changing another member’s role, and role changes take effect in a newly issued or refreshed session token. Existing API keys keep their stored scopes and must be reviewed or revoked separately after a demotion.

Verify context before acting

Open Settings → Account to confirm the signed-in email, organization, and role. In the CLI, use anectico projects list and anectico projects use <slug> before a write. For automation, prefer a project-scoped key rather than relying on the operator to remember a project flag.

Owners and admins can open Settings → Audit to inspect the organization audit trail. The view shows actor, action, resource, result, time, and allowlisted target context; it deliberately omits network identifiers, user agents, and arbitrary metadata. Members, developers, and viewers do not receive audit:read by default. For API-key lifecycle events, the verified user or API-key actor is shown separately from the key being created, renamed, scope-edited, or revoked. If an older event did not record an actor, the view says the actor is unknown rather than guessing from the target.

• Authentication and API keys
• Permissions and safe actions