The words these docs use, in one place. Each entry links to the page that explains it in full.
Account
Integration. The connection to the Totem API that an administrator creates in Settings → Developers: a name and the teams it reads, with an optional description and IP allowlist. The interface calls this Create API key. Its id starts with prn_, and GET /v1/me describes it. See Authentication.
Key. The secret, starting with tsk_live_, that your server sends in the Authorization header. It belongs to one integration. Totem shows it once; you can roll it or revoke it at any time. See Authentication.
Team. A workspace in Totem, with its own boards, members, leads, calls, conversations and bookings. Its id starts with team_. A key reads one team or several, and requests for one team's collections name it in the Totem-Team header when the key has several. See Authentication.
Organization. A billing account and its sub-teams. One integration can cover several teams, as long as they belong to the same organization. In Settings → Developers, an integration that covers several of its teams has the access scope Selected family teams, and API names such as family_transfer and family_origin refer to it. See Authentication.
Family administrator. An administrator of an organization's billing account who is also listed on it as a family administrator. Only a family administrator can create or change an integration that covers several teams. See Authentication.
Member. A person in a team, known by display name only. Member ids start with mem_ and belong to one team: the same person has a different id in each team. See GET /v1/members.
CRM records
Board. A pipeline that a team uses to organize its leads, with its stages in order. Board ids start with brd_. See GET /v1/boards.
Stage. One step of a board, such as "Contacted". Stage ids start with stg_. A lead's stage names the step it is on, and stages travel inside their board. See GET /v1/boards.
Lead. A person or company a team works with, with their place in the pipeline, their origin and their contact permissions. Lead ids start with lead_. See the Leads reference.
Client. A record of the leads endpoints with record_kind: "client". It has no pipeline status, so its status is null. See GET /v1/leads.
Activity. One stage, status or assignee change of a lead. An activity never changes once written. Activity ids start with act_. See GET /v1/leads/{id}/activities.
Facet. A part of a lead that the API delivers as an object of its own, with the lead's id and a version of its own. A lead has two: its attribution, where it came from, and its response, how the team has responded to it across conversations and calls. A new message changes the response, not the lead. See GET /v1/leads/{id}.
Call. The metadata of a phone call with a lead, such as its direction, duration and outcome. Never a recording or a transcript. Call ids start with call_. See the Calls reference.
Conversation. The metadata of a conversation with a lead on one channel, such as its status and when the last messages came and went, without the messages themselves. Conversation ids start with conv_. See the Conversations reference.
Booking. An appointment on the team's calendar: booked for a bookable service, an event from the connected calendar, or an import from an external booking system. Booking ids start with bkg_. See the Bookings reference.
Bookable service. Something people can book with the team, such as a first consultation, held online, in person or by phone. Its id starts with svc_. See GET /v1/booking_services.
Sync
Changes feed. GET /v1/sync/changes: every change to one team's records, in order, page by page. Each item is a record of one kind, or a removal. See Keep a copy in sync.
Cursor. An opaque string that marks your place in a list or in the changes feed. Store it as you received it, and never build or edit one. A changes-feed cursor belongs to one team, and stops working 30 days after the point in the feed it reached or, while an initial sync is still running, that many days after the sync started. See Lists and pagination and Save the cursor.
Version. An integer on every record the changes feed delivers, which grows each time the record changes. Apply an item only when its version is greater than the one you hold. See Conventions.
Initial sync. The first pass through the changes feed, without a cursor. It delivers every record of the team, then catches up with the changes made meanwhile. See Run the initial sync.
Full resync. A new initial sync that rebuilds your copy of a team, after 410 sync_cursor_expired or 409 resync_required. It works by mark and sweep: forget the versions you stored, mark every record the feed delivers and, once it has caught up, delete every record of that team you did not mark. See Full resync.
Removal. A changes-feed item with removed instead of object. Delete your copy of that record, everywhere you copied it. Its reason says why: deleted or erased. See Removals.
Deletion. A removal with reason: "deleted": the record went away in Totem without being erased. See Removals.
Erasure. A removal with reason: "erased": the record was erased for privacy reasons, for example because the person exercised the right to erasure (GDPR Article 17), or because someone permanently deleted a lead, a call or a conversation in Totem, which always erases it. See How do I honor erasure requests? in the FAQ.
Tombstone. What you keep after you apply a removal: the record's kind, id and version, without its data. It stops an older copy of the record, delivered again later, from bringing it back. See Apply a page.
Merge. Two leads for the same person, combined into one. The merged lead is not removed: it stays as an archived lead whose merged_into names the lead that carries on. See Merges.
Transfer. A lead moved to another team of the same organization. The original stays as an archived lead whose transferred_to names the destination team, and the destination lead when Totem can name it. The destination team may be one your key does not read. See Transfers.
Limits and errors
Rate limit. How fast a key may read: up to 2,000 items a minute, with bursts of up to 10,000. Past it, the API answers 429 rate_limited with Retry-After. See Rate limits.
Daily quota. How many items a key may read in one UTC day from the changes feed and every list, including teams, members, bookable services and a lead's activities: 250,000 items, or 3 times the number of records in its teams if that is more. Single-record lookups, search and GET /v1/me do not count. Past it, those endpoints answer 429 quota_exceeded until 00:00 UTC. See Daily quota.
livemode. A field on every resource. It is true on everything the API returns, and false on the example data of these docs and of the kit's fixtures.json. See Conventions.
Request id. The Totem-Request-Id header of every response the API itself sends, repeated as request_id in an error body. Quote it when you ask for help. See Support.
Error code. The code of an error body, such as team_required. Branch on it, and look it up on the Errors page.