Catalog

GET /api/v1/x/catalog is the definition for the firm on the token. Read it before you create a record, a field, or an automation step. A key that is not in it is rejected, and nothing is stored.

GET /api/v1/x/openapi names the routes and the class of each one. It does not list the firm’s fields.

There is no separate schema route for one record type. The schema for companies is the recordTypes entry whose key is Company.

catalogVersion

The response includes catalogVersion, sixteen lowercase hex characters. Send it back on a write as expectedCatalogVersion when you need the write to fail if the catalog moved. A mismatch is 409 catalog_conflict.

The version changes when a system field, a custom field, a relation, an action key, a connector operation’s published contract, or an automation node type’s config changes. It also changes when a record type gains or loses an operation. It does not change because your permissions changed, and it does not change because a form, a saved view, or a quick action was saved.

catalogVersion does not lock a record. Without If-Match, two patches of the same company both succeed, and the later one wins. With If-Match, a stale version is 412 version_conflict. Send expectedCatalogVersion when the write should fail because a field or an action was added or removed.

Names

The same firm object has a different name on each surface. Use the name that surface already uses.

You are calling	Send
A record, a custom field, or a process	The catalog key: Company, Person, LegalEntity
A saved view	The grid: companies, deals, people
A quick action	The sparkle key: company, person, entity

Company on a record is company on a quick action and companies on a view. LegalEntity is entity on a quick action. company on a record call is 400 unknown_entity.

Record types

Each entry has key, module, label, operations, and fields.

operations is what this API will accept for you: get, list, create, update, and relate. An operation is missing when your role lacks it, or when this API does not read or write that type yet.

These types can be read and written when the role allows it:

Type	View	Create	Update
Company	core.company.view	core.company.create	core.company.edit
Person	core.person.view	core.person.create	core.person.edit
Deal	investments.deal.view	investments.deal.create	investments.deal.manage
Lead	investments.deal.view	investments.deal.create	investments.deal.manage
Investor	ir.investor.view	ir.investor.manage	ir.investor.manage

Company and Person can also relate. Deal, Lead, and Investor cannot.

Any other catalog key is still real. Calling it for a record is 400 invalid_parameter: the type is in the catalog, and this API does not read or write it yet. A string that is not a catalog key, including company and PortCo, is 400 unknown_entity.

User and Role are never created or edited here.

Fields

Each field has key, label, valueType, required, writable, clearable, filterable, and custom. A choice field includes options. A custom field uses the stored name, such as thesis_fit. There is no second spelling.

writable: false means sending that key on a create or patch is 400. clearable: false means null will not clear it. filterable is what a list filter or sort may name.

Company requires name and companyType. Person requires firstName and lastName. The catalog is the full list, including the firm’s own fields.

Relations and actions

Relations say how two record types connect. writable: true is only Company to Person (people) and Person to Company (companies). Both create a current company role. The other relations are listed so you can see them. They are not writable here.

Actions are what an automation step may call, including connector operations you are allowed to run. Each one has actionKey, displayName, entityType, description, parameters, and definitionRevision when it comes from a connector. Copy the key from this list. An unknown key is rejected when the automation is saved.

Node types

nodeTypes is the config for an automation node. It is the same for every firm. Each entry has type, label, description, aliases, and config.

A config entry has name, valueType, required, description, and allowedValues when the designer offers a fixed set. Config values are strings. Copy these keys when you build a timer, a condition, a notification, or any other step. A system_action node also takes actionKey from actions, and that action’s parameters are further config keys on the node.

aliases are other type strings stored as the same step. human_task is a task. event_wait is a wait_for. An unknown type is stored as an action. A config key that is not listed is stored and may be ignored. The server adds the end of a for_each. Do not send for_each_end.