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

# Zeno in Claude (Desktop & Code)

> Connect Claude directly to your books and work as yourself from the terminal — with you in control of every write.

The **Zeno operator** connects Claude Desktop or Claude Code straight to your
Zeno organization. Claude acts **as you** — the same login, the same
permissions, the same org — reading and writing across every module you can
reach, with bookkeeping as home base. It's the same engine as the in-app
[AI Bookkeeper](https://zenorent.com/docs/ai-bookkeeper.md), given the full API surface and a terminal to
work in.

> [!NOTE]
>
> This is a power tool. Claude has your access, so it can post transactions,
> enter bills, and run reports — but it is instructed to **name any irreversible
> action and wait for your go-ahead** before doing it. You stay in control.

Books in QuickBooks Desktop rather than Zeno? You want
[Zeno for QuickBooks Desktop](https://zenofirm.com/quickbooks-desktop), which connects Claude to a
company file on your own machine and needs no Zeno account.

## What you can do with it

* **Categorize and reconcile** — find bank-register lines by check number,
  payee, amount, or date; categorize them; run reconciliation.
* **Enter checks, deposits, and bills** — type them in, or hand Claude a PDF
  and let the document pipeline parse and post it (with a review gate).
* **Resolve anything** — "who is Ridgeline?", "find the Operating Checking account" — Claude
  looks across vendors, customers, accounts, and even other modules
  (development projects, glass jobs, rental properties and tenants).
* **Answer questions from the ledger** — AP/AR aging, P\&L, balance sheet, a
  vendor's open bills, a customer's payment history.
* **Reach any module you can** — development, glass, practice, scheduling,
  reports — the same as if you'd clicked into it in the app.

## Get started

> **[Connecting](https://zenorent.com/docs/operator/connecting.md)**
>
> OAuth from Claude Code or Desktop, static tokens, and how to check the connection.

> **[Bulk bookkeeping](https://zenorent.com/docs/operator/bulk.md)**
>
> Folders of documents, categorization backlogs, importing transactions, attaching evidence.

> **[Reconciling](https://zenorent.com/docs/operator/reconciling.md)**
>
> Hand it a statement and let it match the account and surface the differences.

## Staying in control

### Inspecting campaign designs

While you are in Campaigns, every page is listed under **Campaigns** in the
sidebar: your campaigns; **Audience** (contacts, lists and signup forms,
segments, custom fields, import, and do-not-email); **Library** (templates, images
and documents); and **Style guide**. Each page has its own URL, so you can bookmark it
or open it in a separate browser tab.

The **Style guide** is everything your AI reads before writing. Its overview
shows where each part stands. **Look & feel** shows your name, colors, fonts
and footer on a labeled sample newsletter, and you can edit them there or ask
your AI to. **Organization facts** and **Dos & don'ts** hold what your AI must
know and the rules each issue is checked against. The sample newsletter also
appears when the campaign list is empty. Viewing it does not create a
campaign; ask your AI to draft your first issue.

Open **Preview & Design** on an existing campaign to open its own page and see its
finished email alongside the blocks that make it up. **Structure** shows the
ordered content and decorative shapes; select a block to highlight it in the
preview and inspect its styling. **Assets** shows the logo and images used in
the design, with links to their blocks. **Brand** shows the current colors and
fonts used for the preview. **Page** shows the email width, canvas and footer
settings. Switch between desktop and mobile previews; the page refreshes
automatically after AI edits. Each content block in a column is inspectable.

These design details are read-only. Ask your AI to change the campaign, using
a block's name or reference. The AI can adjust section colors, fonts, padding,
borders, image sizing and focal position, button appearance, dividers, column
proportions and decorative shapes. It can compose one to three columns of
independent blocks, customize header logos and subtitles, style event cards,
use background images with fallback colors, and adjust italic text, tracking,
capitalization and decoration. A single `layout` block controls email width,
page colors, corners, header visibility and footer styling, while preserving
the mailing address and unsubscribe link. `campaign_design_controls` describes the
supported fields; `campaign_get_design` reads the same inventory shown in the
app. `campaign_update_blocks` with `patch_block` changes only the supplied
fields and preserves the rest of the content and styling.

Campaign authoring, brand changes, template and list management, and requested
single-recipient test sends do not require an extra browser approval click.
Bulk sending still requires explicit approval in the app. Operation receipts
and organization permissions continue to apply.

Content and campaign-detail changes are saved as a new revision and clear any
pending send approval. Shared brand changes also clear pending send approvals.
Duplicate a sent campaign before redesigning it. Templates retain the design
settings for reuse. Preview and test the result before sending; email clients
can differ in their support for rounded corners and image cropping.

### Turning a flyer or document into a newsletter

A flyer, poster, PDF, Word document or slide deck is source material, not the
email. Your AI rebuilds its words as real headings, text, event cards with
date, time and place, and buttons for links and RSVPs, tightening the copy and
applying your brand kit. Only genuine photos, logos and artwork stay as
pictures, cut out of the page. A whole flyer pasted as one image is unreadable
with images turned off, invisible to screen readers and hard to read on a
phone, so the AI does not do it unless you ask for a small thumbnail.

Drop the file under **Flyers and documents** on the **Images** page (images,
PDF, Word or PowerPoint, up to 25 MB). These files stay private; only the
pieces the AI crops out join the public image library. The AI reads the file
with `campaign_read_source` (or reads a flyer already in the image library by
its name), crops photos and logos with `campaign_crop_source_image`, and then
shows you the preview and says what it rebuilt as text and what it kept as
images. If a file is too blurry or is mostly artwork, the AI says what it
could not read and asks for the original file or a sharper export rather than
guessing dates or links.

When an issue looks like a picture of a flyer (almost no text beside its
images, alt text that transcribes a page, or an image named as a flyer,
poster or full page), **Checks** asks a person to confirm it before sending.

### Teaching your newsletter

**Style guide → Overview** walks you through your organization, its dos and
don'ts, and what needs checking before an issue goes out. Add entries yourself, or give your AI past newsletters and guidelines to
extract proposed facts and instructions. Review the proposals and finish setup
before your first send. You can return to the setup page later.

**Organization facts** holds key people and their preferred titles, locations,
programs, calendar practices, audience guidance and approved wording. Facts
have a source, a confirmation status and an optional expiration date. Mark
information **Internal context only** when it should help the AI understand
the organization without granting permission to publish it.

**Dos & don'ts** groups instructions into **Always do**, **Don't**, and **Check
before sending**. Set each one's importance to **Required**, **Preference**, or
**Human review**. Exact-text checks can test whether a phrase is present or
absent. Use a review for meaning, factual accuracy, image content or permission.
AI-inferred instructions start as proposals; activate or remove them before
completing setup.

The **Checks** tab beside an issue's preview shows automatic results,
unresolved reviews and their evidence. Select a referenced section to highlight
it in the email. Record what you verified, or why a review does not apply to
that issue. Required checks block sending until resolved; preferences remain
visible. Automatic text failures must be fixed in the content or playbook.
Human-review checks require confirmation in the app. Unknown is never treated
as passed, and text matching does not independently verify a fact or read an image.

Content, audience, brand or editorial-context changes make earlier reviews
out of date. The server checks readiness again when you approve a send and
preserves that review with the sent issue. Expired or unconfirmed facts and
possible internal information are flagged; literal matches in the newsletter
require a person's review.

Your AI uses the same records through `campaign_get_editorial_context`,
`campaign_save_organization_profile` and `campaign_save_playbook`. Read
`campaign_get_checks` after edits and before requesting a send. AI assessments
use `campaign_review_check` with evidence and the current issue fingerprint;
they cannot satisfy human-review requirements.

### Building site proposals

With the Sites module enabled, your AI builds and edits website proposals:
a homepage concept, a sample newsletter and design notes for each prospective
client, shown on the public proposal site (not indexed by search engines).
Start with `site_design_controls`. It returns the proposal format, the
homepage section types, the page markup that styling can target, and every
design preset with its CSS as an example.

A homepage starts with an opening section (headline, photograph and this
week's schedule) and can continue with features, events, classes, people,
a full schedule, banners, text, a gallery and contact details. Ask your AI to
add, reorder, restyle or remove any of them. `site_update` changes the
proposal's identity, design, benefits, design notes or newsletter, and
`site_update_sections` changes one section at a time.

A proposal's overall look comes from a **design preset**: stored CSS chosen
with `design.layout`. Colors, paper and font recolor any preset. Web fonts
come from Google Fonts or Bunny Fonts. `design.custom_css` styles a single
proposal. When your AI designs a look worth reusing, it saves it as a new
preset with `site_save_preset`. Styling can rearrange and decorate the page,
but cannot add new HTML elements or scripts.

Edits change a draft. The AI gives you a preview link before it publishes.
`site_publish` makes the draft live without a browser approval, and enabling
a proposal lists it in the directory. A preset change appears in previews at
once and on a live proposal the next time it is published. Every save is a
revision. `site_revisions` and `site_restore` (or `site_restore_preset`)
undo changes. To take a proposal down, disable it; proposals cannot be deleted.

Images for proposals go in the Sites image library: `site_list_images` gives
your AI the upload page for an image you have in chat, and `site_upload_image`
takes a small file directly. It is separate from the Campaigns image library,
so a pitch's images never mix with your own newsletters.

In the app, **Sites** shows every proposal with its status. A proposal's page
previews the draft homepage at desktop, tablet and phone widths, and the
newsletter beside it. Click a section to see what it is made of and the
reference your AI uses for it. From there you can publish the revision you
are looking at, show or hide the proposal, and restore any earlier revision.
**Design presets** lists each preset with its CSS, the proposals that use it,
and its earlier versions.

### Reviewing actions

* **It's you, bounded by you.** The connection grants exactly what your own
  login grants over the API — your role, your org. It never elevates. If you
  can't do something in the app, Claude can't either.
* **Review when the server requires it.** Routine authorized work proceeds.
  Bulk sends, card charging or storage, access changes, unrestorable deletes,
  and unclassified mutations are prepared for review. The link shows the
  organization, effects, values and file metadata. Your approval covers that
  exact request for 24 hours. Return to the conversation to continue it.
* **A bill can't exist without its document.** The server refuses any bill posted
  through the connection unless the source document rides along. The check is on
  the write itself, so no tool path types a bill in from memory.
* **Document entry has a computed review gate.** The server checks its own parse
  confidence against Claude's read and blocks the commit, with reasons, when they
  disagree. Approval is recorded in your browser; a model-supplied
  `human_confirmed` flag cannot bypass it.
* **Everything is audited under you.** Writes are stamped with your user and the
  Claude session, so the audit trail shows exactly what was done and when.
* **Verify in aggregate.** Claude is told to let you confirm its work with the
  right report or balance, not to ask you to eyeball every row.

## Work across modules

The connection starts with `get_context`: the current organization and timezone,
enabled modules, effective access, roles, grants and scopes. Named reads cover
rental, development, contractor, Glass, Practice, expenses, budgeting, tasks,
documents, chat, scheduling, reports and administration. `get_guide` describes
each workflow, including integration readiness and long-tail API operations.

`search_entities` finds candidates in the app's existing search providers;
`inspect_entity` reads supported references without losing their organization.
Search covers books, rental, development, contractor, Glass, Practice and
documents. Its per-type limits mean an absent match is not proof of absence.
Other queues have their own context tools and filters.

`get_glass_context` starts with small summaries of drafts, estimates, current
jobs and unscheduled backlog. Choose a queue and follow `next_offset` for more;
choose `dispatch` with `work_date` for a date's board. A denied queue remains
unknown, queues can overlap, and source caps are explicit. Drafts are local
intake records; reading them does not refresh GlassBiller.

`glass_part_quote` marks incomplete pricing or vendor lookups as partial and
identifies the failed checks. Unknown stock is not an out-of-stock answer,
and a part match without working pricing is not a confirmed quote.

Use `read_api` for JSON reads, `download_file` for original files and exports,
and `upload_file` for multipart uploads (up to 20 MiB). Bill and contract document
creation must use `parse_document` followed by `commit_bill` or `commit_document`;
generic uploads refuse those endpoints. High-confidence bills with agreeing
second reads proceed directly; low confidence, mismatches and duplicate
overrides require browser review. Known settings reads
that create records are excluded from the read-only tool. Partial failures and
truncated lists are reported explicitly. Route discovery describes the global
API catalog; it does not grant access to those routes.

Named actions include rent escalations, development milestone completion,
contractor status changes, Glass technician completion, reviewed Practice
intake, expense receipt approval, recurring task completion, budget debt plans
and Practice appointment booking. Appointments can send confirmation email;
the server's effect classification determines whether review is required.
Other operations remain available through `describe_route` and `call`.

## Receipts and retries

Every mutation through the Operator forwarder is recorded before dispatch.
Named actions require the expected organization and a stable request ID; older
tools accept these as optional fields for compatibility. Supply both on new
work. An organization mismatch refuses the request before dispatch.

Reuse the same request ID and exact arguments when resuming or retrying.
Completed requests are not sent twice. Changed arguments with the same ID are
refused. `get_operation` shows the durable status and any read-back verification.
Some asynchronous work remains pending; generic writes may have no automatic
read-back. A timeout or crash can leave an uncertain receipt, which must be
checked against the actual record before another attempt. This is duplicate
admission protection, not an exactly-once transaction across external systems.

When a write returns success but its read-back is unavailable, the result is
partial success with a warning. A read-back that disagrees with the expected
record is a verification failure. Neither condition permits automatic replay.
After checking the affected records, the requesting person can record an
investigation on the operation page: verified completion or closure without
confirmed completion, with a required note. A running claim becomes eligible
after 15 minutes. Closing an investigation never cancels work or releases its
request ID for reuse; late responses remain visible alongside the person's note.

## Skills, preferences, knowledge and history

`get_context` returns optional role preferences per person and organization.
The AI asks about the person's responsibilities, offers role presets or a custom
description, and saves their answers with `save_operator_preferences`. These
preferences shape questions and suggestions without changing access or the tool
catalog. Onboarding introduces Skills to every user and remembers that lesson.

`list_skills` searches short descriptions across accessible modules and returns
continuation offsets. `get_skill` loads one set of instructions and validates
its arguments. `save_skill` creates or updates a draft using the last-read
revision. Every user can author personal Skills or propose team Skills. The
owner activates a personal Skill; a module manager activates a team Skill.
Personal Skills remain private, including from other managers. Team drafts are
visible to their author and module managers; active team Skills reach module
users. Legacy procedures keep a separate restricted audience and cannot read
new personal or team rows through old API paths.

People create, edit, move and activate Skills at `/operator/memory`. Activation
refuses a version that changed after it was read and requires a browser session.
Active accessible Skills also appear in MCP prompts with paginated discovery.
These stored instructions are not installed native client Skill packages.

`get_module_knowledge` and `draft_module_knowledge` retain manager-level access
to module-wide judgment. `log_work` accepts a module
and optional entity reference; `get_work_history` shows managers the module's
history and other members only their own entries.

Skill command names remain unique across the organization. Omit `slug` when
creating a Skill to derive a unique name from its title. Supply an existing
`slug` and its `updated_at` only when editing or moving that Skill. Knowledge
entries retain their existing explicit-slug creation behavior.

## Getting good answers

* **Say the number, not the id.** "Find transaction 1183" means the *check /
  reference number* on the line — Claude searches for that. (Those fields are
  fully searchable; if Claude ever says it "can't see" a field, that's wrong —
  tell it to search by reference number, payee, or amount.)
* **Name the entity.** Full vendor/customer names and account names resolve
  fastest.
* **Give it the document.** For a bill or contract, attach the PDF rather than
  re-typing the figures — the pipeline dedupes and posts it with the source
  attached.
* **Work in one conversation.** Claude keeps context, so "now categorize that
  one to Repairs" just works.

## How it works

The tools call the same Zeno API your browser does, in-process,
carrying your token — so posting, dedup, and the audit stamp all stay
server-of-record. Claude discovers endpoints with `list_routes()` /
`describe_route()`, resolves names with `whois()`, finds register lines with
`find_transactions()`, and enters documents through the
`parse_document → commit_bill` pipeline. It reads a built-in field guide
(`zeno://guide/recipes`) that maps common jobs to exact endpoints.


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