Zum Hauptinhalt springen

Resources

The ZeyOS REST API exposes a comprehensive set of resources covering CRM, project management, ticketing, commerce, communication, and more. Each resource maps to a RESTful endpoint under the base URL and supports a consistent set of operations.

API Surface vs. CLI Surface

This page documents the full API surface exposed by ZeyOS. The CLI intentionally supports a curated subset of common resources. For the CLI boundary and escalation path, see CLI Coverage and Escalation.

Available Resources​

The table below lists all available API resources and their supported operations.

ResourceEndpointListGetCreateUpdateDelete
Accounts/accountsYesYesYesYesYes
ActionSteps/actionstepsYesYesYesYesYes
Addresses/addressesYesYesYesYesYes
Applications/applicationsYesYes------
ApplicationAssets/applicationassetsYesYes------
Appointments/appointmentsYesYesYesYesYes
Associations/associationsYesYesYesYesYes
BinFiles/binfilesYes--------
Campaigns/campaignsYesYesYesYesYes
Categories/categoriesYesYesYesYesYes
Channels/channelsYesYesYesYesYes
Comments/commentsYesYesYesYesYes
Components/componentsYesYesYesYesYes
Contacts/contactsYesYesYesYesYes
ContactsToContacts/contactstocontactsYesYesYesYesYes
Contracts/contractsYesYesYesYesYes
Coupons/couponsYesYesYesYesYes
CouponCodes/couponcodesYesYesYesYesYes
CustomFields/customfieldsYesYes------
DAVServers/davserversYesYesYesYesYes
Devices/devicesYesYesYesYesYes
Documents/documentsYesYesYesYesYes
DunningNotices/dunningnoticesYesYesYesYesYes
DunningToTransactions/dunningtotransactionsYesYesYesYesYes
EntitiesToChannels/entitiestochannelsYesYesYesYesYes
Events/eventsYesYesYesYesYes
FeedServers/feedserversYesYesYesYesYes
Files/filesYesYesYesYesYes
Follows/followsYesYesYesYesYes
Forks/forksYesYes------
Groups/groupsYesYes------
GroupsToUsers/groupstousersYesYes------
Invitations/invitationsYesYesYesYesYes
Items/itemsYesYesYesYesYes
Ledgers/ledgersYesYesYesYesYes
Likes/likesYesYesYesYesYes
Links/linksYesYesYesYesYes
MailingLists/mailinglistsYesYesYesYesYes
MailingRecipients/mailingrecipientsYesYesYesYesYes
MailServers/mailserversYesYesYesYesYes
Messages/messagesYesYesYesYesYes
MessageReads/messagereadsYesYesYesYesYes
Notes/notesYesYesYesYesYes
Objects/objectsYesYesYesYesYes
Opportunities/opportunitiesYesYesYesYesYes
Participants/participantsYesYesYesYesYes
Payments/paymentsYesYesYesYesYes
Permissions/permissionsYesYes------
PriceLists/pricelistsYesYesYesYesYes
PriceListsToAccounts/priceliststoaccountsYesYesYesYesYes
Prices/pricesYesYesYesYesYes
Projects/projectsYesYesYesYesYes
Records/recordsYesYesYesYesYes
RelatedItems/relateditemsYesYesYesYesYes
Resources/resourcesYesYes------
Services/servicesYesYes------
StockTransactions/stocktransactionsYesYesYesYesYes
Storages/storagesYesYesYesYesYes
Suppliers/suppliersYesYesYesYesYes
Tasks/tasksYesYesYesYesYes
Tickets/ticketsYesYesYesYesYes
Transactions/transactionsYesYesYesYesYes
Users/usersYesYes------
Weblets/webletsYesYes------

Common Resources​

The following resources are the most frequently used when building integrations with ZeyOS.

Tickets​

Support and service tickets with status tracking, priority levels, due dates, and assignment to users. Tickets are the central work item in ZeyOS and can be linked to accounts, projects, contacts, and tasks.

JavaScript
// List open tickets sorted by priority
const tickets = await client.api.listTickets({
  filters: { visibility: 0, status: 4 },
  sort: ['-priority', '+duedate'],
  limit: 50,
});

// Get a single ticket with extended data
const ticket = await client.api.getTicket({ ID: 12345, extdata: 1, tags: 1 });

// Create a new ticket
const newTicket = await client.api.createTicket({
  name: 'Server maintenance required',
  priority: 3,
  status: 0,
});

// Update a ticket — flat spread form or explicit body key both work
await client.api.updateTicket({ ID: 12345, status: 4, priority: 4 });
// Equivalent using explicit body key:
// await client.api.updateTicket({ ID: 12345, body: { status: 4, priority: 4 } });

Accounts​

Customer and company records that serve as the primary organizational entity in the CRM. Accounts can have linked contacts, tickets, documents, and transactions.

JavaScript
const accounts = await client.api.listAccounts({
  fields: ['ID', 'lastname', 'firstname'],
  filters: { visibility: 0 },
  sort: ['+lastname'],
  limit: 100,
});

Contacts​

Individual people linked to accounts. Contacts store personal details such as name, email, phone, and address information.

JavaScript
const contacts = await client.api.listContacts({
  fields: {
    Id: 'ID',
    Name: 'lastname',
    Email: 'email',
    Company: 'account.lastname',
  },
  filters: { visibility: 0 },
  sort: ['+lastname'],
});

Tasks​

Actionable work items that can be linked to tickets, projects, or other entities. Tasks track completion status and can be assigned to users.

JavaScript
const tasks = await client.api.listTasks({
  filters: { ticket: 12345, visibility: 0 },
  sort: ['+name'],
  limit: 200,
});

Projects​

Organizational groupings for tickets, tasks, and other work items. Projects provide a way to plan and track larger initiatives.

JavaScript
const projects = await client.api.listProjects({
  fields: ['ID', 'name'],
  filters: { visibility: 0 },
  sort: ['+name'],
});

Items​

Products and services with pricing information. Items are referenced in documents (invoices, quotes) and can be linked to price lists, categories, and suppliers.

JavaScript
const items = await client.api.listItems({
  fields: ['ID', 'name', 'price', 'unit'],
  sort: ['+name'],
  limit: 100,
});

Documents​

Business documents such as invoices, quotes, orders, and delivery notes. Documents are linked to accounts and contain line items referencing products/services.

JavaScript
const invoices = await client.api.listDocuments({
  filters: { doctype: 'invoice', visibility: 0 },
  sort: ['-date'],
  limit: 25,
});

Resource Naming​

The API follows consistent naming conventions for endpoints and operations:

Endpoint Paths​

Resource endpoints use plural, lowercase paths:

Text
/accounts
/tickets
/contacts
/documents

Individual records are accessed by appending /{ID}:

Text
/accounts/{ID}
/tickets/{ID}

Operation IDs​

The JavaScript client uses camelCase operation IDs that follow a verb-noun pattern:

OperationPatternExample
Listlist{Resources}listTickets, listAccounts
Getget{Resource}getTicket, getAccount
Createcreate{Resource}createTicket, createAccount
Updateupdate{Resource}updateTicket, updateAccount
Deletedelete{Resource}deleteTicket, deleteAccount
Existsexists{Resource}existsTicket, existsAccount

All operations are available as methods on the client.api object:

JavaScript
// List operations accept query parameters (fields, filter, sort, etc.)
const results = await client.api.listTickets({ limit: 10 });

// Get operations require an ID path parameter
const ticket = await client.api.getTicket({ ID: 123 });

// Create operations accept a request body
const created = await client.api.createTicket({ name: 'New ticket' });

// Update operations require an ID and changed fields (flat spread or explicit body key)
await client.api.updateTicket({ ID: 123, status: 4 });

// Delete operations require an ID
await client.api.deleteTicket({ ID: 123 });

// Exists operations return a boolean-like HEAD response
await client.api.existsTicket({ ID: 123 });
info

The client library is auto-generated from the OpenAPI specification files located in the /openapi/ directory of this project. The spec files (api.json, oauth2.json, auth.json) define every available resource, operation, parameter, and response schema. Run npm run generate to regenerate the client after modifying the spec files.

HTTP Methods​

The API uses the following HTTP methods, which may differ from typical REST conventions:

OperationHTTP MethodDescription
ListPOSTRetrieve a filtered list of records (body contains query parameters)
GetGETRetrieve a single record by ID
CreatePUTCreate a new record
UpdatePATCHPartially update an existing record
DeleteDELETEDelete a record by ID
ExistsHEADCheck if a record exists (returns no body)
tip

Note that list operations use POST rather than GET. This is because the query language (filters, field selection, sorting) can produce request payloads that exceed URL length limits. Using POST allows complex queries to be sent reliably in the request body.