> ## Documentation Index
> Fetch the complete documentation index at: https://docs.linkedcamp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core

> Orientation. Call whoami once at the start of a conversation — the plan it reports decides whether Pro-only steps are usable at all, and permissions gates several features. Call reference before authoring a sequence or filtering by status; the vocabulary is not guessable.

| Tool | Kind |
| - | - |
| [`reference`](#reference) | Read-only |
| [`unread_counts`](#unread_counts) | Read-only |
| [`whoami`](#whoami) | Read-only |

## reference

<Badge color="blue">Read-only</Badge>

The exact enum values, step-field requirements and defaults this API accepts. Read this before authoring a campaign flow or filtering by status — guessing a value produces a validation error, and the vocabulary is not guessable (e.g. campaign settings use the field name `campaginLimits`, spelled that way in the schema). A static vocabulary, not account data — it says which values exist, never which the account has. For the account's own tags, templates, personas or placeholders use `tag_list`, `template_list`, `persona_list` or `placeholder_list`.

### Parameters

<ParamField path="topic" type="all | sequence_steps | triggers | campaign | leads | placeholders | integrations | misc" default="all">
  Narrow the reference to one area to keep the response small.
</ParamField>

## unread\_counts

<Badge color="blue">Read-only</Badge>

Badge counts for notifications, unread conversations, pending activities and open tasks. Counts only, as a cheap way to see whether anything needs attention. For the items themselves use `notification_list`, `conversation_list`, `activity_list` or `task_list`.

*No parameters.*

## whoami

<Badge color="blue">Read-only</Badge>

The authenticated account: name, email, role, plan, entitlements and notification settings. Call this first in a new conversation — the plan tells you whether Pro-only steps (Email, Qualifier, AI Hook, Finder, Event invite) are available, and `permissions` gates several features. For a team-member key this reports the account OWNER, not the team member: the backend resolves such a key to the owner, because that is the account being acted on and the one holding the plan. Identity and entitlements only. It reports no campaign or lead data, and it cannot change anything — profile edits are `account_settings_update`. Read `_derived` before proposing any Pro or permission-gated step, because the refusal from a gated tool is real and has no workaround.

*No parameters.*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.