MCP server
Підключіть AI інструменти до Flowtly через Model Context Protocol на mcp.flowtly.eu.
Підключити
claude mcp add --transport http flowtly https://mcp.flowtly.eu/mcp
На цій сторінці
Agreements_get
Інструменти
| agreements_get | Отримати одну трудову угоду за id — type, variant, період dateFrom/dateTo, hoursPerWeek, а також похідні `calculable`, `active` і `status`. agreements_list надає id. Потребує ROLE_AGREEMENTS_MANAGER або ROLE_MEETING_MANAGER. Лише читання. |
Agreements_list
Інструменти
| agreements_list | Список трудових угод — фільтр за employee (IRI), isActive, type або variant. ЦЕ спосіб відповісти на питання "чому people_list показує цю людину як неактивну": кожен рядок містить `calculable` і `active`, і людина активна лише тоді, коли має угоду, яка є обома одразу. Також тут можна прочитати коди агоди `type`, які реально використовує ця організація, перед викликом agreements_create, бо організація може додавати власні. Потребує ROLE_AGREEMENTS_MANAGER або ROLE_MEETING_MANAGER. Лише читання. |
Agreement Types_get
Інструменти
| agreementTypes_get | Отримати один тип договору за id — його name або translationKey, `calculable`, `isActive`, `position` і `builtIn`. id І Є кодом, тож це читає тип за тим самим рядком, який угода зберігає в `type`. Використовуйте це, щоб підтвердити, що тип збережено після agreementTypes_create, і перевірити `calculable` перед тим, як призначати його комусь. Потребує ROLE_USER. Лише читання. |
Agreement Types_list
Інструменти
| agreementTypes_list | Список типів договорів, які ЦЯ організація може призначити угоді — значення за `Ludzie > <person> > Umowy > Edytuj umowę`. Читайте це перед agreements_create або agreements_import, бо список є для кожного тенанта окремо: постачається п'ять вбудованих типів ("agreement", "annex", "termination", "list-of-intent", "work-experience"), і організація може додавати власні, тож `type`, дійсний в одній організації, поверне 422 в іншій. ID І Є КОДОМ — `id` кожного рядка є точно тим рядком, якого `agreements_create` очікує в `type`, а не числовим ключем для пошуку. `calculable` — це поле, яке визначає, чи робить володіння цим типом людину АКТИВНОЮ і чи враховує її в resourcing bench, нарахуванні відпустки та базі витрат; тип без calculable залишає людину неактивною без жодної помилки, що є навмисним для типу на кшталт "list-of-intent" і прихованим багом, якщо його обрали випадково. Рядки `builtIn` мають translationKey і порожній (null) name; власні рядки мають name, що рендериться дослівно, і порожній (null) translationKey. Потребує ROLE_USER. Лише читання. |
Allocations_get
Інструменти
| allocations_get | Одна алокація за id — бронювання однієї людини на проєкт, із датами та відсотком зайнятості. allocations_list знаходить id; цей запит читає повний запис. Алокація без співробітника — це ВІДКРИТА роль (незаповнена потреба), а не бронювання. Потребує модуля ресурсування. Лише читання. |
Allocations_list
Інструменти
| allocations_list | Список алокацій ресурсування — призначення позиції на проєкті співробітнику (або поки нікому — відкрита роль) у певному діапазоні дат. Без фільтрів; пагінація через курсор. Кожен елемент уже містить розв'язані employeeId/employeeName та projectId/projectName (null employeeId означає відкриту роль); positionId подається без розшифровки — знайдіть назву через positions_list. source розрізняє рядки, імпортовані з таблиці, від створених безпосередньо у Flowtly. Використовуйте це, щоб звірити імпорт таблиці ресурсування: перевірте, що потрапило в систему, і порівняйте з тим, що було надіслано. |
Asset Bookings_get
Інструменти
| assetBookings_get | Отримати одне бронювання активу за id — актив, його утримувача, дати та чи його скасовано. Лише читання. |
Asset Bookings_list
Інструменти
| assetBookings_list | Список бронювань активів — хто або що наразі утримує кожен актив; саме це прив'язування показує екран Assets, і це єдине місце, де реально зберігається зв'язок актив-людина. Кожен рядок містить актив, утримувача (`relationName` employee | project плюс `relationId`), дати початку/кінця, а після звільнення — `cancelReason` і `cancelledAt`. Фільтруйте за `property`, щоб побачити історію одного активу, або за `employee`, щоб побачити все, що утримує одна людина — саме це варто запустити перед звільненням співробітника. Зауважте, що `employee` тут — ЧИСЛОВИЙ id, а не /people IRI, який приймає assetBookings_create. Додайте `exists.cancelledAt: false`, щоб побачити лише те, що досі утримується; без цього список включає й звільнені бронювання. Лише читання. |
Asset Meter Readings_get
Інструменти
| assetMeterReadings_get | Отримати одне показання лічильника за id — його лічильник, дату та значення. Лише читання. |
Asset Meter Readings_list
Інструменти
| assetMeterReadings_list | Список показань лічильників — датовані значення, записані для лічильника активу; це сирі дані, які читає розподіл metered-billing. Кожен рядок містить лічильник, дату та значення. Використовуйте це, щоб прочитати історію лічильника: значення, яке не змінюється між періодами (застряглий або спільний лічильник), виставляється нулем, а лічильник без нещодавніх рядків — це той, який ніхто не знімає. Лише читання. |
Asset Meters_get
Інструменти
| assetMeters_get | Отримати один лічильник активу за id — актив, на якому він встановлений, тип комунальної послуги, одиницю виміру та зовнішній/QR-ідентифікатор, разом із його показаннями. Лише читання. |
Asset Meters_list
Інструменти
| assetMeters_list | Список лічильників активів організації — лічильники комунальних послуг/медіа, встановлені на активах (електрика, вода, газ, тепло). Кожен містить актив, на якому він встановлений, тип комунальної послуги, одиницю виміру та показання. Фільтруйте за `property` (актив, якому він належить) та `utilityType`. Використовуйте це, щоб визначити id лічильника, який приймають показання, та щоб знайти лічильники, які показують нуль, застрягли на одному значенні або встановлені на спільному/колективному лічильнику. Лише читання. |
Assets_get
Інструменти
| assets_get | Отримати один актив за id — name, status, категорію (attributeSet), parent, assetCode, серійний номер, дати покупки та гарантії, локацію та налаштування бронювання. Лише читання. |
Assets_list
Інструменти
| assets_list | Список активів організації — реєстр фізичних речей, якими вона володіє або які продає, від ноутбуків і столів до квартир, паркомісць і складських приміщень. Фільтруйте за status (in-stock | damaged | sold), attributeSet (категорія, за якою групує список Assets), bookingAllowed або частковим збігом name чи serialNumber; сортуйте за name, status, serialNumber, boughtAt або warrantyTo. БЕЗ ПАГІНАЦІЇ — весь набір повертається в одній відповіді, тож великий реєстр — це один великий payload, а не перша сторінка. Використовуйте це, щоб визначити id активу, який приймають бронювання активів і документи активів. Лише читання. |
Attribute Entity Values_list
Інструменти
| attributeEntityValues_list | Список ЗНАЧЕНЬ атрибутів — що конкретний актив, проєкт, бюджет чи клієнт фактично має для прив'язаного атрибута. Кожен рядок містить атрибут, значення та `relationId`, що називає сутність, якій він належить. Лише читання. |
Attributes_get
Інструменти
| attributes_get | Отримати одне визначення атрибута за id — name, type, чи є обов'язковим або множинним, значення за замовчуванням і формат-шаблон. Лише читання. |
Attributes_list
Інструменти
| attributes_list | Список ВИЗНАЧЕНЬ атрибутів — іменовані поля (площа, поверх, ціна), які прив'язуються до категорій і для яких активи мають значення. Кожне має type: number | string | date | state | period. Лише читання. |
Attribute Set Attributes_list
Інструменти
| attributeSetAttributes_list | Список прив'язок між категоріями та визначеннями атрибутів — які поля з'являються в якій категорії. Лише читання. |
Attribute Sets_get
Інструменти
| attributeSets_get | Отримати один набір атрибутів за id — його name, relationName, icon та прив'язані до нього атрибути. Лише читання. |
Attribute Sets_list
Інструменти
| attributeSets_list | Список наборів атрибутів організації — КАТЕГОРІЇ, за якими класифікують актив, проєкт, бюджет або клієнта. Фільтруйте за relationName: "property" для категорій активів (те, що в UI називається Typ zasobu і за чим групує список Assets), а також "project", "budget" і "client". Звертайтеся сюди перед створенням нового: категорія, продубльована через написання чи регістр, тихо розділяє список, який вона групує, і ніщо в UI цього не пояснює. Лише читання. |
Bank Accounts_get
Інструменти
| bankAccounts_get | Отримати один банківський рахунок за id — назва, валюта, банк і формат, у якому імпортуються його виписки. |
Bank Accounts_list
Інструменти
| bankAccounts_list | Список банківських рахунків організації. Фільтруйте за банком або встановіть hidden, щоб включити архівні. Використовуйте, щоб визначити bankAccount id, за яким фільтрує transactions_list. |
Banks_get
Інструменти
| banks_get | Отримати один банк за id — установу, а не рахунок, відкритий у ній. Використовуйте bankAccounts_get для рахунку. |
Banks_list
Інструменти
| banks_list | Список банків, у яких відкриті рахунки організації. Приховані банки ВКЛЮЧЕНІ за замовчуванням — передайте hidden=false для вигляду селекторів або hidden=true, щоб знайти виведені з обігу. Використовуйте це, щоб визначити id банку, за яким фільтрує bankAccounts_list і який потрібен bankAccounts_create. |
Budgets_employee Pnl
Інструменти
| budgets_employeePnl | P&L по кожному співробітнику для бюджету — що заробив час кожної людини порівняно з тим, скільки вона коштувала. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Budgets_get
Інструменти
| budgets_get | Отримати один бюджет за id — його період, область охоплення та налаштування. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Budgets_list
Інструменти
| budgets_list | Список бюджетів організації — періоди, для яких плануються та порівнюються доходи й витрати. Використовуйте це, щоб визначити id бюджету, який приймає кожен інструмент pnl. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Clients_get
Інструменти
| clients_get | Отримати одного клієнта за id — назва, країна, валюта, податковий номер і статус. |
Clients_list
Інструменти
| clients_list | Список клієнтів (замовників організації). Фільтруйте за статусом або за externalPaymentCustomerId, щоб знайти клієнта за id платіжного провайдера. Використовуйте, щоб визначити client id, за яким фільтрують invoices_list, deals_list, projects_list і contracts_list. |
Config Keys_catalog
Інструменти
| configKeys_catalog | Список усіх ключів конфігурації організації, які розпізнає бекенд, із типом та допустимими значеннями. Це каталог того, що можна налаштувати — читайте його перед configs_get або configs_update, а не вгадуйте назву ключа. Дозволи перевіряються бекендом для кожного ключа окремо, тож наявність ключа тут не гарантує, що підключений користувач може його змінювати. |
Configs_get
Інструменти
| configs_get | Читання одного значення конфігурації організації за id, де id — це ключ із configKeys_catalog (наприклад, organization-logo-url, organization-icon-url). |
Contracts_get
Інструменти
| contracts_get | Отримати один договір за id — сторони, напрямок, суму, циклічні умови та дати. |
Contracts_list
Інструменти
| contracts_list | Список договорів. Фільтруйте за direction — збережені значення: "out" (ми продаємо / виставляємо) і "in" (ми купуємо / отримуємо), а також "unknown" — реальний, придатний для фільтрації стан, а не помилка. Договір, створений завантаженням документа, починається як "unknown" і залишається таким, доки вилучення даних або людина не визначить його статус, тож пропустіть фільтр, щоб отримати всі три: "in" і "out", запитані окремо, НЕ СКЛАДАЮТЬСЯ в увесь набір (flowtly-mcp#130). НЕ "outgoing"/"incoming": вони нічого не збігають і повертають порожній список замість помилки. Також фільтрує за counterparty, project, cyclic, name або tags. Використовуйте це, щоб визначити id договору, який читає contracts_paymentScheduleLines і з яким deals_win може пов'язати виграну угоду. |
Contracts_payment Schedule Lines
Інструменти
| contracts_paymentScheduleLines | Список графіка платежів договору — платежі, які очікується виставити або оплатити. Передайте contractId з contracts_list. Це план, а не факт: порівняйте його з transactions_list, щоб побачити, що реально сплачено. Сума кожного рядка — у МІНІМАЛЬНИХ ОДИНИЦЯХ — грошах, не злотих: "530000" — це 5 300,00, тож поділіть на 100, перш ніж повідомляти цифру комусь. |
Cost Groups_list
Інструменти
| costGroups_list | Список груп витрат / центрів витрат — категорій, за якими класифікуються витрати, постачальники та вхідні рахунки. Використовуйте, щоб визначити costGroup id, який вимагає suppliers_create і який пропонують підказки для вхідних рахунків. |
Counterparties_get
Інструменти
| counterparties_get | Отримати одного контрагента за id. |
Counterparties_list
Інструменти
| counterparties_list | Отримати список контрагентів — усіх сторін, з якими взаємодіє організація. Прапорці supplier і client показують, яку роль(і) відіграє контрагент, і один запис може мати обидві. Це сторона банківської транзакції, тому саме з нею зіставляються вхідні рахунки й транзакції. Фільтруйте за type, supplier, client, cyclic або budgetNeutral. |
CRM Notes_get
Інструменти
| crmNotes_get | Отримати одну нотатку CRM за id. |
CRM Notes_list
Інструменти
| crmNotes_list | Отримати список нотаток, залишених на лідах і угодах. Фільтруйте за lead або deal, щоб прочитати коментарі до конкретного запису. |
Deal Lost Reasons_get
Інструменти
| dealLostReasons_get | Отримати одну причину втрати угоди за id. |
Deal Lost Reasons_list
Інструменти
| dealLostReasons_list | Впорядкований список причин, за якими угоду можна позначити як програну. deals_lose вимагає lostReasonId звідси. |
Deals_get
Інструменти
| deals_get | Отримати одну угоду за id — назва, клієнт, етап, сума, власник, контакт, очікувана й фактична дата закриття. |
Deals_list
Інструменти
| deals_list | Отримати список угод/можливостей — воронку продажів. Фільтруйте за status (open / won / lost), stage, owner, client, lead або за діапазонами expectedCloseDate / closedAt. Суми вказані в мінорних одиницях з явною валютою; не покладайтеся на валюту організації за замовчуванням. |
Deal Stage Histories_get
Інструменти
| dealStageHistories_get | Отримати один запис про зміну етапу угоди за id. |
Deal Stage Histories_list
Інструменти
| dealStageHistories_list | Список переходів угоди між етапами, від найновіших. Фільтруйте за угодою. Кожен deals_update, що змінює етап, автоматично фіксується тут, тож саме так можна відновити, скільки часу угода перебувала на кожному етапі — сама угода зберігає лише поточний етап. |
Departments_list
Інструменти
| departments_list | Відділи організації з числовим id, за яким на кожен посилаються. ПРОЧИТАЙТЕ ЦЕ ПЕРЕД people_create ЧИ people_update: обидва приймають IRI `department`, і немає іншого способу дізнатися дійсний. Колекція без пагінації та впорядкована за name, тож один виклик повертає всі відділи організації. Фільтруйте за `name` (частковий збіг) або `code` (точний збіг). Рядки містять id, name і code; `manager` — це зв'язок, і його немає в рядках списку — читайте його з people_list з іншого боку, якщо потрібно. Потребує ROLE_EMPLOYEES_VIEWER. Лише читання. |
Holiday Days Limits_get
Інструменти
| holidayDaysLimits_get | Один рядок нарахування за id — сума, тип, варіант договору та дата набуття чинності. holidayDaysLimits_list знаходить id. Суми в СЕКУНДАХ (#3763). Лише читання. |
Holiday Days Limits_list
Інструменти
| holidayDaysLimits_list | Скільки відпустки ПОЛОЖЕНО кожній людині за кожним типом — не скільки вона взяла, це holidays_list. Фільтруйте за employee. Людина може мати кілька рядків для одного типу протягом часу, бо баланс поповнюється або коригується: чинним є рядок з найпізнішою dateFrom, яка вже настала, а рядки з датою в майбутньому свідомо ігноруються до настання. Суми в СЕКУНДАХ (#3763) — 8-годинний день відпустки це 28800. Потребує ROLE_HOLIDAYS_MANAGER. Лише читання. |
Holiday Requests_list
Інструменти
| holidayRequests_list | ЗАПИТИ на відпустку та їхній статус — очікує, схвалено, відхилено. Відрізняється від holidays_list, де зберігається заброньована відпустка: запит, що ще очікує рішення, не є відсутністю, тож плануйте за holidays_list, а цей ресурс використовуйте, щоб побачити, що очікує на чиєсь рішення. Надає holidayRequestId, який приймають holidays_approve і holidays_bulkApprove. Лише читання. |
Holidays_active
Інструменти
| holidays_active | Хто відсутній ПРЯМО ЗАРАЗ — усі відпустки, що тривають на цей момент, у всій організації, для всіх. Це інструмент для запиту 'хто відсутній сьогодні', і його варто перевірити перед тим, як трактувати freePercent із resourcingBench_get як доступність, оскільки резерв не віднімає відпустки. На відміну від holidays_list, він не обмежується проєктом і не вимагає жодних дозволів, окрім входу в систему, тож відповідь охоплює всю організацію. Повертає кожну відсутність з її типом і датами. Лише читання. |
Holidays_get
Інструменти
| holidays_get | Один запис відпустки за id, із типом, датами та тривалістю. Отримайте id з holidays_list або holidays_active. Лише читання. |
Holidays_list
Інструменти
| holidays_list | Заброньована відпустка за період — планове представлення, тоді як holidays_active відповідає лише про сьогодні. Фільтруйте за співробітником, діапазоном дат або проєктом. ТЕ, ЩО ВИ БАЧИТЕ, ЗАЛЕЖИТЬ ВІД ВАШИХ ДОЗВОЛІВ, і короткий список не є доказом того, що ніхто не відсутній: менеджер з відпусток або бухгалтерський переглядач бачить усю організацію, тоді як керівник або переглядач проєкту ПОВИНЕН передати фільтр за проєктом (або запитати про себе) і без нього отримує пряму відмову — ця відмова є межею дозволів, а не порожнім календарем. Лише читання. |
Holiday Types_list
Інструменти
| holidayTypes_list | Типи відпусток, які використовує ця організація, з id, за яким на кожен посилаються. Читайте це перед holidayDaysLimits_create/update, які потребують IRI holidayType, інакше його доведеться вгадувати. Той, що не є відпусткою у звичайному сенсі — `pick-up-day` — відгул за вже відпрацьовані понаднормові (польське *odbior nadgodzin*), який є НАРАХОВАНИМ балансом, а не річним правом на відпустку. Лише читання. |
Incoming Invoices_get
Інструменти
| incomingInvoices_get | Отримати один вхідний (постачальницький) рахунок або супровідний документ за id, з полями, розпізнаними через OCR, і поточним станом зіставлення. |
Incoming Invoices_list
Інструменти
| incomingInvoices_list | Список вхідних (постачальницьких) рахунків і супровідних документів — бухгалтерська вхідна скринька. Вхідний рахунок Є документом, приєднаним до банківської транзакції, тож exists.transaction=false — спосіб знайти документи, які ще не зіставлені з платежем. Також фільтруйте за status, relatedMonth, counterparty, project, tags або hasDetectedProblems. Кожен документ має відбиток externalId 'upload_sha256:<sha256 байтів>' — обчисліть хеш файлу і знайдіть цей externalId тут ПЕРЕД incomingInvoices_create, інакше ви завантажите дублікат. |
Incoming Invoices_match Candidates
Інструменти
| incomingInvoices_matchCandidates | Отримати список банківських транзакцій, які можуть бути оплатою цього вхідного рахунку, ранжований власним алгоритмом зіставлення бекенду. Використовуйте його, коли до документа не прикріплена транзакція і потрібно її обрати; надавайте перевагу цим кандидатам, а не вгадуванню за сумами самостійно. |
Incoming Invoices_suggestions
Інструменти
| incomingInvoices_suggestions | Читання власних пропозицій Flowtly для вхідного рахунку — відповідність постачальника, група витрат, відповідна банківська транзакція, попередження про дублікат. Це саме ті пропозиції, які людина бачить у застосунку. Спершу прочитайте їх, потім застосуйте одну за id через incomingInvoices_applySuggestion або прийміть усі через acceptAllSuggestions. Передайте refresh, щоб перерахувати, а не віддавати кешований набір. |
Incoming Invoices_suggestions Debug
Інструменти
| incomingInvoices_suggestionsDebug | Пояснює, ЧОМУ пропозиції для вхідного рахунку вийшли саме такими — оцінку алгоритму зіставлення, для діагностики відсутньої або хибної пропозиції. Лише для діагностики; для звичайної роботи використовуйте incomingInvoices_suggestions. |
Initial Budget Items_list
Інструменти
| initialBudgetItems_list | Список позицій початкового бюджету — заплановані суми за тегами, з якими зіставляє contractComparison. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Initial Budgets_contract Comparison
Інструменти
| initialBudgets_contractComparison | ЗАПЛАНОВАНО проти ЗАКОНТРАКТОВАНО, за тегами — заплановані суми початкового бюджету проти суми фактично підписаних значень договорів для цього проєкту. Це відповідь на питання "чи взяли ми на себе більше зобов'язань, ніж заплановано, і де саме", і вона читається напряму з договорів, які вже є в організації, тож імпорт договорів робить це доступним без додаткової роботи. Суми в грошах; проєкт зі змішаною валютою видає попередження замість тихо неправильного підсумку. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Initial Budgets_get
Інструменти
| initialBudgets_get | Отримати один початковий бюджет за id, разом з його позиціями. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Initial Budgets_list
Інструменти
| initialBudgets_list | Список початкових бюджетів — ПОЧАТКОВИЙ план для проєкту чи інвестиції, на відміну від актуального бюджету, з яким його порівнюють. Потребує ROLE_BUDGETS_VIEWER. Лише читання. |
Invoices_get
Інструменти
| invoices_get | Отримати один вихідний (продажний) рахунок за id — клієнт, позиції, підсумки, дата продажу й виставлення, статус. |
Invoices_list
Інструменти
| invoices_list | Список вихідних (продажних) рахунків. Фільтруйте за клієнтом, тегами, пошуком або діапазоном saleDate. Зауважте, що саме saleDate — не дата виставлення й не дата створення — є полем, за яким фільтрує invoices_export, тож використовуйте те саме поле тут при звірці експорту. |
Lead Activities_get
Інструменти
| leadActivities_get | Отримання однієї активності ліда (контакту в рамках залучення) за id. |
Lead Activities_list
Інструменти
| leadActivities_list | Список контактів залучення ліда — хронологія активностей (надіслане запрошення, відповіді, дзвінки, подальші контакти). Фільтруйте за лідом, щоб прочитати історію одного потенційного клієнта. Це структурований аналог crmNotes_list: активності — це типізований журнал контактів з датами; нотатки — довільний коментар. |
Lead Contacts_get
Інструменти
| leadContacts_get | Отримати один контакт ліда за id. |
Lead Contacts_list
Інструменти
| leadContacts_list | Отримати список контактних осіб, прикріплених до лідів. Фільтруйте за lead, щоб прочитати контакти одного потенційного клієнта, або за email, щоб знайти, від якого ліда надійшло повідомлення. |
Lead List Memberships_get
Інструменти
| leadListMemberships_get | Отримати один запис членства ліда в списку за id. Його status і lastContactedAt — це знімок, записаний викликачем, а не актуальний стан — див. leadListMemberships_list. |
Lead List Memberships_list
Інструменти
| leadListMemberships_list | Список того, які ліди перебувають у яких списках для outbound-прозвону. Фільтруйте за list, lead або status. ОБЕРЕЖНО: status і lastContactedAt — це ЗНІМОК, записаний тим, хто останнім імпортував чи оновив членство. Вони не обчислюються, і ніщо не просуває їх, коли фіксується активність — запис хвилі з 529 фолоу-апів не зрушить жодне з полів — тож вони можуть бути як завгодно застарілими. Щоб відповісти на питання "коли ми востаннє контактували з цим потенційним клієнтом", читайте натомість журнал активностей: leadActivities_list для одного ліда, leadActivities_byList для цілої кампанії. leadListMemberships_syncFromActivities показує розрив і може його закрити. |
Lead Lists_get
Інструменти
| leadLists_get | Отримати один список для вихідного пошуку клієнтів за id. |
Lead Lists_list
Інструменти
| leadLists_list | Список списків для вихідного пошуку потенційних клієнтів. Використовуйте, щоб визначити list id, який приймає leadListMemberships_create. |
Lead Lost Reasons_get
Інструменти
| leadLostReasons_get | Отримати одну причину втрати ліда за id. |
Lead Lost Reasons_list
Інструменти
| leadLostReasons_list | Отримати впорядкований список причин, за якими ліда можна позначити як втраченого. |
Leads_dedupe Check
Інструменти
| leads_dedupeCheck | Перевірка, чи потенційний клієнт уже є в CRM, з використанням тих самих фільтрів, що й leads_list (companyName, source, owner, …). Викликайте це ПЕРЕД leads_create: дублікат ліда розділяє історію залучення на два записи, і жоден подальший процес не об'єднає їх за вас. |
Leads_get
Інструменти
| leads_get | Отримати одного ліда за id — компанія, сайт, джерело, статус, власник і клієнт, у якого він конвертувався, якщо є. |
Leads_list
Інструменти
| leads_list | Список лідів — потенційних клієнтів до кваліфікації. Фільтруйте за status, source, owner, client, companyName або діапазонами createdAt/closedAt. Кваліфікований лід стає клієнтом і відкритою угодою через leads_convert; до цього моменту він існує лише тут, а не в clients_list. |
Lead Stages_get
Інструменти
| leadStages_get | Отримати один етап ліда за id. |
Lead Stages_list
Інструменти
| leadStages_list | Впорядкований список етапів, через які проходить лід. Ліди мають власний набір етапів — угоди використовують stages_list, це інша сутність. |
Locations_get
Інструменти
| locations_get | Отримати одну локацію за id — її name та години роботи офісу. Лише читання. |
Locations_list
Інструменти
| locations_list | Список локацій організації — фізичні місця, де перебувають активи, показані в UI як Lokalizacja. Потребує ROLE_LOCATIONS_MANAGER, який незвично обмежує й ЧИТАННЯ, і запис. Лише читання. |
Organization Addresses_get
Інструменти
| organizationAddresses_get | Отримати один запис адреси підписки за id — name, street, city, postCode, country та податкові поля. `street` містить номер будівлі, якщо його введено вручну, і не містить, якщо адресу отримано з пошуку NIP/GUS. Лише читання. |
Organization Addresses_list
Інструменти
| organizationAddresses_list | Список записів адреси підписки організації — адреса, прив'язана до підписки Flowtly, і джерело, з якого рендериться {{organizationAddress}} у підвалі листа. Зазвичай рівно один рядок. Це НЕ адреса продавця для рахунків-фактур, яка зберігається в конфіг-ключах organization-billing-* (configs_get) і яку читають рахунки-фактури та KSeF; ці два сховища ведуться окремо і регулярно розходяться. Прочитайте обидва, перш ніж робити висновок, яке з них клієнт фактично редагував. Лише читання. |
Organizations_get
Інструменти
| organizations_get | Отримання організації за id. ПОПЕРЕДЖЕННЯ — це НЕ повідомляє, до якої організації ви підключені. Підключення OAuth прив'язане рівно до однієї організації (через токен), але цей ендпоінт повертає будь-яку організацію, учасником якої є підключений КОРИСТУВАЧ, тож успішне читання тут може виглядати як підтвердження роботи саме в цій організації, хоча це може бути не так. Щоб перевірити орендаря, з яким ви справді працюєте, читайте дані, обмежені орендарем, — people_list або clients_list — і ніколи не починайте масовий запис лише на підставі цього виклику. |
People_get
Інструменти
| people_get | Отримати один запис особи/співробітника за id — імена, електронні адреси, телефон, керівник і чи є він активним. |
People_list
Інструменти
| people_list | Отримати список осіб/співробітників. Фільтруйте за isActive, reportsTo (id керівника), projectMembers.project або search; використовуйте пагінацію через cursor. People та employees мають спільний id, тож саме так визначається employee id, якого очікують інструменти для обліку часу, відповідальностей, участі в проєктах і дозволів. |
Permission Groups_get
Інструменти
| permissionGroups_get | Отримати одну групу дозволів за id, включно з рядками ROLE_*, які вона надає. |
Permission Groups_list
Інструменти
| permissionGroups_list | Список груп дозволів організації та ролей, які надає кожна з них — наприклад, група "Business Owner" надає ROLE_ADMIN. Читайте це перед people_setPermissionGroups: ролі у відповіді є достовірним джерелом того, що насправді дозволяє група, тож не потрібно вгадувати за її назвою. |
Pipelines_get
Інструменти
| pipelines_get | Отримати одну воронку продажів за id. |
Pipelines_list
Інструменти
| pipelines_list | Список воронок продажів. Воронка має впорядкований набір етапів — читайте їх через stages_list з фільтром за воронкою. |
Positions_list
Інструменти
| positions_list | Список позицій — іменованих ролей (наприклад, "Backend Engineer"), які заповнює алокація проєкту. Без фільтрів; для Position пагінацію вимкнено, тож цей виклик завжди повертає повний каталог ролей організації за один раз. Кожен елемент — це {id, name, roles}. Використовуйте, щоб визначити назву позиції за positionId рядка allocations_list, і знайти position id, з яким має збігатися імпорт ресурсування. |
Project Members_get
Інструменти
| projectMembers_get | Отримати одне членство в проєкті за id — його employee, project та position. Id беруться з projectMembers_list або з масиву projectMembers у projects_get. |
Project Members_list
Інструменти
| projectMembers_list | Список членств у проєктах — ХТО МОЖЕ БАЧИТИ ЯКИЙ ПРОЄКТ. Фільтруйте за project (`/projects/{id}`), щоб прочитати склад одного проєкту, або за employee, щоб прочитати всі проєкти, доступні одній людині; кожен рядок містить власний id, employee, project і position (employee|tech-lead|account-manager|viewer). Звертайтеся сюди першим, коли хтось повідомляє, що проєкт зник зі списку Projects або не може логувати час на нього: порожній склад, або склад без цієї людини, І Є поясненням — видимість це і є членство. Це також джерело id для projectMembers_update і projectMembers_delete. Зауважте, що та сама людина може з'являтися в проєкті кілька разів, по одному разу на кожну позицію. |
Projects_cost Allocations
Інструменти
| projects_costAllocations | Як витрати були розподілені НА цей проєкт — які транзакції та рядки рахунків-фактур були віднесені до нього і в якій частці. Використовуйте це, щоб пояснити показник прибутковості, а не просто процитувати його: саме тут несподіваний результат простежується до документа, який його спричинив. Потребує ROLE_TRANSACTIONS_MANAGER. Лише читання. |
Projects_folder Counts
Інструменти
| projects_folderCounts | Скільки проєктів лежить у кожній ТЕЦІ проєктів, у вигляді folderId + total + active. folderId — це id tagDefinition: назви отримайте через tagDefinitions_list, а які групи є групами тек — через tagGroups_list (allowedRelations містить "project"). Порожній folderId — це кошик без категорії. Рахує лише кореневі проєкти, бо теки групують корені, а фази йдуть за батьківським проєктом. Лише читання. |
Projects_get
Інструменти
| projects_get | Отримати один проєкт за id — назва, тип, клієнт, дати, опис і ціна. |
Projects_list
Інструменти
| projects_list | Отримати список проєктів. Фільтруйте за type (fixed-price | time-and-material | non-billable | internal), client.name, employee, name або діапазонами dateFrom/dateTo. Використовуйте це, щоб визначити id project, якого очікують завдання, облік часу, бюджети та договори. |
Projects_profitability
Інструменти
| projects_profitability | РЕЗУЛЬТАТ ПО ПРОЄКТУ — що заробив проєкт порівняно з тим, скільки він коштував. Це число, яке зазвичай намагається побачити сервісний чи девелоперський бізнес, і те, яким живляться всі інші інструменти для проєктів. Передайте id проєкту з projects_list. Потребує ROLE_ACCOUNT_MANAGER. Лише читання. |
Project Templates_get
Інструменти
| projectTemplates_get | Отримати один шаблон проєкту за id, разом з повним документом структури. projectTemplates_list знаходить id. Прочитайте це перед projectTemplates_update — структура записується ЦІЛКОМ, тож оновлення має надіслати повний документ, а не фрагмент. Лише читання. |
Project Templates_list
Інструменти
| projectTemplates_list | Список шаблонів проєктів організації — придатні для повторного використання креслення проєкту, його фаз, списків завдань і завдань. Звертайтеся сюди ПЕРЕД projects_create, коли та сама форма проєкту налаштовується знову і знову (тип угоди, аудит, онбординг): інстанціювання шаблону будує все дерево одним викликом, тоді як projects_create створює порожній проєкт, який потім доводиться заповнювати вручну. Рядок з позначкою isDefault — це вбудований шаблон організації, який застосовується до проєкту, створеного без вибору шаблону. Лише читання. |
Resource Request Candidates_get
Інструменти
| resourceRequestCandidates_get | Один кандидат на найм за id. Id надходить з resourceRequestCandidates_list. Потребує ROLE_HR_MANAGER. Лише читання. |
Resource Request Candidates_list
Інструменти
| resourceRequestCandidates_list | Кандидати, висунуті на запити про найм — люди у воронці найму, а не співробітники, доступні для алокації. Фільтруйте за id запиту з resourceRequests_list. Потребує ROLE_HR_MANAGER. Лише читання. |
Resource Requests_get
Інструменти
| resourceRequests_get | Один запит на найм за id, з позицією та статусом. Отримайте id з resourceRequests_list. Це HR/найм, а не алокація ресурсування. Потребує ROLE_HR_MANAGER. Лише читання. |
Resource Requests_list
Інструменти
| resourceRequests_list | Відкриті запити на найм — запит на пошук кандидата на позицію, у сфері HR. Попри назву, це НЕ попит на алокацію ресурсування: це найм. Повертає колекцію; resourceRequests_get читає один запис, а resourceRequestCandidates_list дає людей, висунутих на нього. Потребує ROLE_HR_MANAGER. Лише читання. |
Resourcing Requests_list
Інструменти
| resourcingRequests_list | Відкриті запити на ресурсування — прохання виділити людину на проєкт, тобто сторона попиту в ресурсуванні. Це потік, який відображає вигляд Requests в інтерфейсі ресурсування. НЕ плутайте з resourceRequests_list: це HR-НАЙМ (пошук кандидата на позицію). Поєднуйте з resourcingRequestsHistory_list, щоб дізнатися, що вже вирішено, і з resourcingBench_get, щоб знайти, хто може задовольнити запит. Потребує модуля ресурсування та ROLE_RESOURCING_MANAGER. Лише читання. |
Resourcing Requests History_list
Інструменти
| resourcingRequestsHistory_list | Те, що вже відбулося із запитами на ресурсування — журнал рішень (підтверджено, відхилено, змінено) за відкритими запитами з resourcingRequests_list. Використовуйте, щоб відповісти на питання 'чи це вже запитували й відхилили?' перед тим, як знову пропонувати ту саму алокацію. Потребує модуля ресурсування та ROLE_RESOURCING_MANAGER. Лише читання. |
Responsibilities_get
Інструменти
| responsibilities_get | Отримати одну відповідальність за id. |
Responsibilities_list
Інструменти
| responsibilities_list | Отримати список відповідальностей у групі RACI. Фільтруйте за responsibilityGroup. Відповідальності можуть бути вкладеними через parent; людей призначають на них через responsibilityEmployees, а не напряму. |
Responsibility Employees_get
Інструменти
| responsibilityEmployees_get | Отримати одне призначення відповідальності за id. |
Responsibility Employees_list
Інструменти
| responsibilityEmployees_list | Отримати список того, хто на яку відповідальність призначений і з яким відсотком. Фільтруйте за employee, щоб побачити повне навантаження RACI однієї людини в усіх групах. |
Responsibility Groups_get
Інструменти
| responsibilityGroups_get | Отримати одну групу відповідальності за id. |
Responsibility Groups_list
Інструменти
| responsibilityGroups_list | Отримати список груп відповідальності / зон RACI — елементів верхнього рівня "Odpowiedzialności", кожен із яких має відповідальну особу. Окремі відповідальності підпорядковані їм. |
Schedule Employees_get
Інструменти
| scheduleEmployees_get | Одне призначення графіка співробітнику за id. Id надходить з scheduleEmployees_list. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Schedule Employees_list
Інструменти
| scheduleEmployees_list | Які співробітники призначені на які графіки робочого часу. Використовуйте, щоб перейти від графіка (schedules_list) до його людей або знайти графік, за яким працює конкретний співробітник. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Schedule Plan_list
Інструменти
| schedulePlan_list | Графіки, чинні на ОДНУ вказану дату — передайте дату в шляху. Використовуйте, щоб відповісти на питання 'хто працює сьогодні / у цю дату' без читання кожного графіка та самостійного розв'язання його діапазонів. На відміну від інших запитів графіків, цей потребує лише ROLE_USER, тож він доступний звичайному співробітнику. Лише читання. |
Schedule Ranges_get
Інструменти
| scheduleRanges_get | Один часовий діапазон графіка за id. Id надходить з scheduleRanges_list. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Schedule Ranges_list
Інструменти
| scheduleRanges_list | Часові діапазони, з яких складаються графіки робочого часу — фактичні години, які охоплює графік. Спершу прочитайте батьківський запис через schedules_get; цей ресурс розгортає його діапазони. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Schedules_get
Інструменти
| schedules_get | Один графік робочого часу за id, з діапазонами та призначеними співробітниками. Id надходить з schedules_list; scheduleRanges_list і scheduleEmployees_list читають його складові. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Schedules_list
Інструменти
| schedules_list | Графіки робочого часу — змінні/робочі шаблони, визначені організацією, а НЕ алокація на проєкт. Використовуйте resourcingSchedule_get, щоб дізнатися, хто на що заброньований; цей ресурс — для самих робочих шаблонів. schedules_get читає один за id. Потребує ROLE_SCHEDULES_MANAGER. Лише читання. |
Stages_get
Інструменти
| stages_get | Отримати один етап угоди за id. |
Stages_list
Інструменти
| stages_list | Впорядкований список етапів угод. Фільтруйте за воронкою. deals_create вимагає stage id звідси, а переміщення угоди між етапами фіксує dealStageHistories. |
Suppliers_list
Інструменти
| suppliers_list | Отримати список постачальників/підрядників — дані надходять з /contractors, тож "supplier" і "contractor" — це один і той самий запис. Фільтруйте за cyclic для регулярних постачальників. Використовуйте це, щоб визначити постачальника, за яким проведено витрату, договір або вхідний рахунок. |
Tag Definitions_list
Інструменти
| tagDefinitions_list | Список визначень тегів — тегів, які можна прикріпити до записів, кожен у своїй групі тегів. tags_create приймає tagDefinition id звідси разом із записом, до якого його прикріпити. |
Tag Groups_list
Інструменти
| tagGroups_list | Отримати список груп тегів — контейнерів, що впорядковують визначення тегів. |
Task Comments_list
Інструменти
| taskComments_list | Отримати список коментарів до завдань проєкту, від найстаріших. Фільтруйте за task, щоб прочитати обговорення одного завдання. |
Task Lists_list
Інструменти
| taskLists_list | Список списків завдань — колонок/розділів дошки, до яких належать завдання. Фільтруйте за проєктом. tasks_create приймає list id звідси. |
Tasks_get
Інструменти
| tasks_get | Отримати одне завдання проєкту за id — назва, проєкт, статус, список, виконавці, дати й повторення. |
Tasks_list
Інструменти
| tasks_list | Список завдань проєкту. Фільтруйте за проєктом, списком, статусом, виконавцями, isTemplate або діапазонами startAt/dueAt. Повторювані завдання мають recurrenceParent і recurrenceRule, тож згенероване входження можна простежити до правила, яке його створило. Щоб визначити, чи завдання ЗАВЕРШЕНЕ, порівнюйте його статус із taskStatuses_list (isClosed), а не з назвою статусу. |
Task Statuses_list
Інструменти
| taskStatuses_list | Отримати список статусів завдань проєкту в порядку дошки. isClosed позначає завершені стани, а isDefault — статус, який отримує нове завдання. Читайте це перед тим, як інтерпретувати статус завдання — назви налаштовуються організацією, тому рядок "Done" не є надійним критерієм для зіставлення. |
Tax Groups_list
Інструменти
| taxGroups_list | Список податкових груп. Використовуйте, щоб визначити taxGroup id, за яким фільтрує taxRules_list і який містять рядки рахунків. |
Tax Rules_list
Інструменти
| taxRules_list | Отримати список податкових правил — ставок і періодів, до яких вони застосовуються. Фільтруйте за taxGroup. |
Transactions_list
Інструменти
| transactions_list | Отримати список банківських транзакцій — банківської виписки, з якою зіставляються вхідні рахунки. Фільтруйте за bankAccount, counterpartyRole, cost, ignored, hasDetectedProblems, діапазоном orderDate/execDate або amount.between. Зверніть увагу: orderDate і execDate — це різні поля: платіж може бути замовлений в одному місяці, а виконаний у наступному. |
Transactions_suggestions
Інструменти
| transactions_suggestions | Читання пропозицій Flowtly для однієї банківської транзакції — до якого контрагента, групи витрат чи документа її слід віднести. Дзеркальне відображення incomingInvoices_suggestions, з боку грошей. |
Work Times_get
Інструменти
| workTimes_get | Отримати один запис обліку часу за id — дата, хвилини, проєкт, нотатки та співробітник, якому він належить. |
Work Times_list
Інструменти
| workTimes_list | Отримати список записів обліку часу (відпрацьованих годин). Фільтруйте за діапазоном дат (date.after / date.before, YYYY-MM-DD) і за бажанням за employee або project; використовуйте пагінацію через cursor. Кожен рядок містить employeeId/employeeName і projectId/projectName, тож саме так експортуються всі відпрацьовані години за період. ВАЖЛИВО: результати по всій організації вимагають ROLE_WORKING_HOURS_VIEWER. Без цієї ролі бекенд НЕ повертає помилку — він мовчки повертає лише записи підключеного користувача, тож експорт "годин усіх" може повернутися з даними лише однієї людини й виглядати цілком коректно. Якщо всі рядки належать одному співробітнику, а ви не фільтрували за employee, відповідь містить scopeWarning із поясненням цього — покажіть його користувачеві, а не подавайте результат як дані по всій організації. |
Agreements_create
Інструменти
| agreements_create | Створити трудову угоду для людини. САМЕ ЦЕЙ КРОК РОБИТЬ ЛЮДИНУ АКТИВНОЮ: people_create лише створює запис, і людина без угоди назавжди повідомлятиме isActive false — тож масовий імпорт приземляється на 100% неактивним, доки цей виклик не виконано для кожного. ОБИДВІ УМОВИ МАЮТЬ БУТИ ВИКОНАНІ, інакше людина лишається неактивною без жодної помилки: `type` має бути CALCULABLE (вбудовані "agreement", "annex", "termination" такі є; "list-of-intent" і "work-experience" — ні), а вікно dateFrom/dateTo має покривати сьогодні (передайте dateTo null для чинного договору замість далекої дати в майбутньому). `employee` — це IRI — /people/<id> з people_list. Типи розширюються організацією, тож запустіть agreements_list для когось уже активного, щоб побачити коди, які ця організація справді використовує. Потребує ROLE_AGREEMENTS_MANAGER. Запис. |
Agreements_update
Інструменти
| agreements_update | Змінити наявну трудову угоду — саме так угоду ЗАВЕРШУЮТЬ, бо бекенд не має видалення для цього ресурсу: встановіть `dateTo` на останній день, який вона покриває, і людина перестає бути активною з цього моменту, а запис та його історія залишаються цілими. Це правильний крок для рядка, пов'язаного з payroll; немає способу змусити рядок зникнути, і не повинно бути. Це також спосіб виправити неправильний `type`, `variant` чи `positionName` на місці, а не додавати другу угоду поверх людини — ДВІ угоди не скасовують одна одну, calculable-угода продовжує тримати людину активною, тож "додати правильну поруч" тихо залишає неправильну чинною. `amount`, `amountType` і `billingType` приймаються, але API ніколи їх не повертає, тож прочитати назад те, що ви записали, неможливо. Потребує ROLE_AGREEMENTS_MANAGER. Запис. |
Agreement Types_create
Інструменти
| agreementTypes_create | Додати тип договору до списку ЦІЄЇ організації, щоб можна було зафіксувати угоду проти чогось, що не покривають п'ять вбудованих типів — "Umowa zlecenie", "Kontrakt B2B", "Użytkownik funkcyjny". Це конфігурація, а не зміна коду: список — це таблиця для кожного тенанта, і власний тип не потребує запису перекладу, бо його `name` рендериться дослівно в усіх семи локалях. НЕ НАДСИЛАЙТЕ `id`: код формується з name на сервері зі згортанням діакритики ("Użytkownik funkcyjny" стає "uzytkownik-funkcyjny"), і передача id відхиляється з 422 "Update is not allowed for this operation". Надішліть name і прочитайте призначений код з відповіді. `calculable` ЗА ЗАМОВЧУВАННЯМ FALSE І МОВЧИТЬ: воно визначає, хто рахується працевлаштованим — resourcing bench, нарахування відпустки, база витрат і бюджету — тож тип, призначений для людей, які НЕ повинні накопичувати відпустку чи займати FTE, правильно мати false, а тип для реального працевлаштування МАЄ мати true, інакше всі на ньому повідомлятимуть неактивність без жодної помилки. Ніщо не скаже вам, що саме у вас вийшло. `position` впорядковує випадний список; `isActive` за замовчуванням true. Оновлення чи видалення через MCP навмисно немає — `agreement.type` зберігає id цього рядка як простий рядок з… |
Attribute Sets_create
Інструменти
| attributeSets_create | Створити категорію (name + relationName обов'язкові; relationName — одне з property | project | budget | client, а для категорії активу це простий рядок "property" — НЕ IRI). Необов'язкова icon з фіксованого списку (room, parking, building, office, local, desk, monitor тощо), яку UI показує поруч з категорією. СПОЧАТКУ ПЕРЕВІРТЕ СПИСОК: name не унікальне, тож друга "Mieszkanie" приймається і тихо розділяє список Assets надвоє. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Sets_update
Інструменти
| attributeSets_update | Перейменувати категорію, змінити її icon або перенести до іншого relationName. Саме так виправляють категорію, створену з друкарською помилкою, замість дублювання. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attributes_create
Інструменти
| attributes_create | Створити визначення атрибута (name + type обов'язкові; type — number | string | date | state | period). ТИП — ЦЕ РІШЕННЯ: його поділяють усі сутності, що мають цей атрибут, тож поле, створене як `string`, пізніше не можна підсумовувати чи сортувати як число без переписування кожного наявного значення. Визначайте його за тими значеннями, які у вас реально є, а не за першим побаченим. Саме собою визначення нічого не робить — прив'яжіть його до категорії через attributeSetAttributes_create, інакше воно ніде не з'явиться. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attributes_update
Інструменти
| attributes_update | Оновити визначення атрибута — name, type, required, multiple, default або format. Зміна `type` у визначення, яке вже має значення, — найризикованіша дія: наявні значення не конвертуються. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Set Attributes_create
Інструменти
| attributeSetAttributes_create | Прив'язати визначення атрибута до категорії (attributeSet + attribute, обидва IRI). САМЕ ЦЕ РОБИТЬ АТРИБУТ ВИДИМИМ: без прив'язки значення можна успішно записати для сутності, і воно ніколи не з'явиться в UI — збій без жодного симптому. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Set Attributes_delete
Інструменти
| attributeSetAttributes_delete | Відв'язати атрибут від категорії. Визначення та будь-які значення виживають; вони просто перестають показуватися для цієї категорії, що виглядає як втрата даних, хоча нею не є. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Entity Values_create
Інструменти
| attributeEntityValues_create | Встановити значення атрибута для однієї сутності (attribute + value обов'язкові). `relation` — ЦЕ IRI — "/properties/7", а не слово "property": бекенд розв'язує його і виводить назву зв'язку з класу ресурсу, тож передача простого імені викликає помилку. (`relationId` приймає простий id і досі працює, але вважається застарілим на користь IRI.) Атрибут має бути вже ПРИВ'ЯЗАНИЙ до категорії цієї сутності, інакше значення зберігається, але ніколи не показується. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Entity Values_update
Інструменти
| attributeEntityValues_update | Змінити одне значення атрибута на місці, за його id. Використовуйте це замість створення другого значення для тієї самої пари (сутність, атрибут) — унікальність нічим не гарантується, тож дублікат приймається, і UI показує одне з них. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Attribute Entity Values_delete
Інструменти
| attributeEntityValues_delete | Видалити значення атрибута із сутності. Визначення та прив'язка виживають; зникає лише значення цієї сутності. Потребує ROLE_ATTRIBUTES_MANAGER. Запис. |
Departments_create
Інструменти
| departments_create | Додати відділ, щоб можна було приписувати до нього людей. `name` обов'язкове (до 128 символів) і УНІКАЛЬНЕ в межах організації; `code` необов'язкове (до 64) і ТАКОЖ унікальне — скорочена форма, яку організація вже використовує у власних таблицях (CEO, TECH, PROC). `manager` — необов'язковий IRI співробітника з people_list. СПОЧАТКУ ЗАПИТАЙТЕ СПИСОК І ОЧІКУЙТЕ КОЛІЗІЙ: оскільки і name, і code унікальні, повторне надсилання відділу, який уже існує, ЗАВЕРШУЄТЬСЯ ПОМИЛКОЮ, а не є ідемпотентним, тож імпорт, що припускає create-на-рядок, зупиниться на першому відділі, який в організації вже є — типово залишку після пробного періоду. Узгоджуйте цей рядок через departments_update, а не створюйте навколо нього. ВИДАЛЕННЯ НЕМАЄ: бекенд не має видалення для відділу, тож неправильну назву чи код виправляють на місці через departments_update і ніколи не видаляють. Потребує ROLE_EMPLOYEES_MANAGER. Запис. |
Departments_update
Інструменти
| departments_update | Перейменувати відділ, дати йому code або встановити його manager. Це інструмент, який робить імпорт відділів можливим, а не просто зручним: `name` і `code` обидва унікальні, тож відділ, який в організації вже є — той єдиний рядок "HR", який зазвичай лишається після proof-of-concept — не можна створити знову, і реальний список досягається ВИПРАВЛЕННЯМ цього рядка, а не колізією з ним. Змінюються лише поля, які ви надсилаєте, тож передача самого лише `code` лишає name незмінним. `id` — числовий id з departments_list; `manager` — IRI співробітника з people_list. ВИДАЛЕННЯ НЕМАЄ, що робить це повною історією виправлення: відділ, створений з друкарською помилкою, виправляється тут, а той, якого не повинно існувати, можна лише перейменувати, не видалити. Потребує ROLE_EMPLOYEES_MANAGER. Запис. |
Locations_create
Інструменти
| locations_create | Створити локацію (name обов'язкове; необов'язкові officeOpenHour/officeCloseHour як секунди від півночі). Використовуйте реальну адресу, а не назву проєкту чи інвестиції — це те, що потрібно людині, яка стоїть перед активом, а назва проєкту вже зберігається деінде. Потребує ROLE_LOCATIONS_MANAGER. Запис. |
Locations_update
Інструменти
| locations_update | Перейменувати локацію або змінити її години роботи. Потребує ROLE_LOCATIONS_MANAGER. Запис. |
Clients_import
Інструменти
| clients_import | Завантажити БАГАТО клієнтів одним викликом, ключуючись на `externalRef` — інструмент для перенесення списку покупців чи замовників з іншої системи, де clients_create був би одним запитом на людину. Рядки узгоджуються з організацією: невідомий externalRef створює, відомий оновлює на місці, збіжний рядок пропускається, тож повторний запуск нічого не змінює. Ref зберігається як `externalPaymentCustomerId` — єдина колонка зовнішнього посилання, яку має клієнт, і `clients_list` фільтрує саме за нею. НЕ ЗІСТАВЛЯЙТЕ клієнтів за іменем — список покупців повний спільних прізвищ і спільних покупок. Кожен результат містить `counterpartyId`, який потрібен contracts_import і contracts_create. Дві пастки, яких схема не виражає: `tin` ВІДХИЛЯЄТЬСЯ без `tinCountry`, а контактний рядок потребує e-mail, тож самого номера телефону недостатньо для створення. СПОЧАТКУ ПЕРЕДАЙТЕ dryRun:true для реального завантаження при онбордингу. Максимум 500 рядків. Потребує ROLE_CLIENTS_MANAGER. Запис. |
Contracts_import
Інструменти
| contracts_import | Завантажити БАГАТО договорів одним викликом, ключуючись на `name` — номер угоди. На відміну від клієнта чи активу, договір НЕ МАЄ колонки зовнішнього посилання, тож name І Є ключем ідемпотентності; пакет, що містить те саме name двічі, ВІДХИЛЯЄТЬСЯ ЦІЛКОМ, а не оновлює один договір двічі, бо дубльований номер означає, що джерело помилкове. `counterpartyExternalRef` розв'язує покупця через той самий ref, який отримав clients_import, тож ці два складаються: спочатку імпортуйте клієнтів, потім договори, ніколи не працюючи з числовим id контрагента напряму — ref, що не збігається з жодним клієнтом, провалює саме цей рядок, а не створює договір без сторони. `direction` — це "out" (ми продаємо) або "in" (ми купуємо); колонка не має обмеження на боці сервера, тож неправильне слово зберігається, і договір потім не збігається з жодним фільтром. СПОЧАТКУ ПЕРЕДАЙТЕ dryRun:true. Максимум 500 рядків. Потребує ROLE_CONTRACTS_MANAGER. Запис. |
Assets_import
Інструменти
| assets_import | Завантажити БАГАТО активів одним викликом, ключуючись на `assetCode` — інструмент для перенесення інвентарю з іншої системи, де assets_create був би одним запитом на запис. Рядки узгоджуються з організацією: невідомий assetCode створює, відомий оновлює на місці, збіжний рядок пропускається, тож повторний запуск нічого не змінює, і незавершений прогін безпечно повторити. `parentAssetCode` вкладає рядок під інший ЗА ЙОГО КОДОМ, розв'язаним відносно організації та попередніх рядків того самого пакета; батьківський елемент, що не розв'язується, провалює саме цей рядок, а не тихо лишає його без батька. ТРИ ПОЛЯ РОБЛЯТЬ ЗАПИС ЗРОЗУМІЛИМ, а не просто голим іменем: `attributeSetName` — це категорія, яку UI показує як Typ zasobu і за якою групує список, `locationName` — де фізично перебуває річ, а `attributes` — це мапа {name: value} для площі, поверху, ціни та всього іншого, що несе джерело. Усі три розв'язуються ЗА ІМЕНЕМ — категорія, локація, визначення атрибутів та їхні прив'язки знаходяться або створюються за вас, тож викликачу ніколи не доводиться працювати з цими IRI напряму, а імена збігаються без урахування регістру, тож "Mieszkanie" і "mieszkanie " не можуть розділити список надвоє. `attributes` потребує категорії, до якої прив'язатися,… |
Assets_create
Інструменти
| assets_create | Створити актив (name + status + bookingType обов'язкові; status = in-stock | damaged | sold, bookingType = minutes | days | single-days | permanently). bookingType обов'язковий, навіть якщо актив ніколи не бронюють — передайте "permanently" для того, що не здається в оренду, і лишіть bookingAllowed false. Два поля несуть структуру: `parent` вкладає актив під інший (одиницю під будівлю, монітор під стіл), а `attributeSet` встановлює категорію, за якою групує список Assets, і саме там же живуть власні атрибути, такі як площа чи поверх. `assetCode` — УНІКАЛЬНИЙ міжсистемний ідентифікатор — використовуйте його, щоб зберегти id, який цей актив має в системі обліку, звідки його імпортовано, тож повторний імпорт оновлює, а не дублює. Потребує ROLE_PROPERTIES_MANAGER. Запис. |
Assets_update
Інструменти
| assets_update | Оновити актив за id — name, status, категорію, parent, assetCode, серійний номер, дати, локацію чи налаштування бронювання. Саме так актив переходить із in-stock у sold. Зауважте, що словник status — це in-stock | damaged | sold, і немає стану "зарезервовано", тож утримання доводиться моделювати якось інакше. Потребує ROLE_PROPERTIES_MANAGER. Запис. |
Asset Meters_update
Інструменти
| assetMeters_update | Оновити лічильник активу — його мітку, тип комунальної послуги, одиницю виміру або активний стан. Використовуйте це, щоб вивести лічильник з обліку (наприклад, послугу тепер виставляють напряму з рахунку) без видалення історії показань. Потребує ROLE_PROPERTIES_MANAGER. Запис. |
Asset Bookings_create
Інструменти
| assetBookings_create | Призначити актив людині чи проєкту. `property` — це IRI активу (/assets/{id}) і є обов'язковим. Назвіть утримувача ОДНИМ із трьох способів: `relation` з одним IRI (/people/{id} для людини, /projects/{id} для проєкту), або `relationName` (employee | project) плюс `relationId`, або поле IRI `employee` / `project` напряму. Має розв'язатися рівно один утримувач — якщо не названо жодного, відхиляється з "Employee or Project must be set.", а якщо обидва — з "Employee and Project cannot be set at the same time." ДВЕ РЕЧІ, ЯКИХ НЕМАЄ В СХЕМІ І ЯКІ ДАДУТЬ 422: актив має бути вже придатним до бронювання (`bookingAllowed: true` — встановлюється через assets_update), бізнес-правило, що діє для КОЖНОГО викликача, включно з менеджером, з відмовою "This asset is not reservable."; і власний `bookingType` активу (minutes | days | single-days | permanently) — саме він надає сенс `duration` / `endDate` — простір, виділений одній людині безстроково, це `permanently` з `startDate` і без кінця. Одночасні бронювання одного активу серіалізуються на сервері, тож накладання відхиляється, а не подвійно бронюється. Потребує ROLE_PROPERTY_BOOKINGS_MANAGER для бронювання від імені когось іншого. Запис. |
Asset Bookings_update
Інструменти
| assetBookings_update | Оновити наявне бронювання активу — його дати, тривалість, суму/валюту оплати або частку споживання за лічильником. `relationName` і `relationId` обов'язкові в payload, тож передавайте того утримувача, якого бронювання вже має, якщо тільки ви навмисно не переносите його. Щоб завершити призначення, використовуйте assetBookings_cancel, а не endDate у минулому. Потребує ROLE_PROPERTY_BOOKINGS_MANAGER. Запис. |
Asset Bookings_cancel
Інструменти
| assetBookings_cancel | Звільнити актив — саме так завершується призначення, і це найближче, що цей ресурс має до видалення (операції видалення немає). Приймає id бронювання та `cancelReason` довжиною 3–255 символів; бронювання зберігається і позначається `cancelledAt`, тож історія виживає, а актив стає вільним для наступного утримувача. Це виклик, який роблять, коли співробітник звільняється: assetBookings_list, відфільтрований за `employee`, знаходить усе, що він утримує, а цей інструмент звільняє кожен запис. Потребує ROLE_PROPERTY_BOOKINGS_MANAGER. Запис. |
Work Times_log
Інструменти
| workTimes_log | Залогувати запис робочого часу для підключеного користувача Flowtly (date, durationMinutes, project, notes). ПРИМІТКА МАЄ ПРОЙТИ СЕРВЕРНУ ПЕРЕВІРКУ НА ЗАНАДТО КОРОТКИЙ ОПИС, з якою регулярно стикається пакетне довантаження: потрібно АБО приблизно 32 символи (точна межа — це налаштування на рівні організації, і організація може встановити 0, щоб вимкнути перевірку), АБО посилання на тікет з "#", АБО http(s)-посилання — досить будь-чого одного. "Flowtly – Scallier" відхиляється; "Flowtly – Scallier #FLOW-123" — ні. 422 називає propertyPath `description` — так сервер називає поле, яке цей інструмент називає `notes`. Запис. |
Tasks_create
Інструменти
| tasks_create | Створити завдання проєкту (обов'язкові title і project; необов'язкові status, list, assignees, dueAt, priority). Запис. |
Tasks_update
Інструменти
| tasks_update | Оновити завдання проєкту за id — змінити status (зокрема позначити виконаним), assignees, dueAt, title тощо, або ПЕРЕНЕСТИ завдання в інший проєкт, передавши `project` (зміна батька; список завдань очищається, якщо тільки ви також не назвете `list` у цільовому проєкті, бо список належить одному проєкту). Запис. |
Task Comments_create
Інструменти
| taskComments_create | Додати коментар до завдання проєкту (id завдання + content). Запис. |
Suppliers_create
Інструменти
| suppliers_create | Створити новий запис постачальника/підрядника (обов'язкові name, tinType, costGroup). Запис. |
Suppliers_update
Інструменти
| suppliers_update | Оновити дані постачальника/підрядника (name, податковий номер, умови оплати тощо) за id. Запис. |
People_create
Інструменти
| people_create | Створити запис особи/співробітника (обов'язкові firstname і lastname; необов'язкові companyEmail, contactEmail, contactPhone). Запис. |
People_update
Інструменти
| people_update | Оновити запис особи/співробітника за id (name, companyEmail, contactEmail, contactPhone тощо). Запис. |
People_delete
Інструменти
| people_delete | Видалити запис співробітника/особи за id (наприклад, щоб прибрати тимчасового/тестового співробітника). Вимагає ROLE_EMPLOYEES_MANAGER; бекенд запускає процесор видалення, який також від'єднує пов'язані записи. Значний вплив, незворотно. Запис. |
Cost Groups_create
Інструменти
| costGroups_create | Створити групу витрат / центр витрат (обов'язкові name і type). Запис. |
Cost Groups_update
Інструменти
| costGroups_update | Оновити назву або тип групи витрат / центру витрат за id. Запис. |
Tag Groups_create
Інструменти
| tagGroups_create | Створює групу тегів (назва обов'язкова), щоб упорядкувати пов'язані визначення тегів. Так само створюється контейнер ТЕКИ ПРОЄКТІВ: передайте allowedRelations: ["project"], і визначення цієї групи стануть теками у списку проєктів. Група з порожнім allowedRelations є універсальною і НЕ вважається текою. Запис. |
Tag Definitions_create
Інструменти
| tagDefinitions_create | Створює визначення тега (обов'язкові name, level, tagGroup) у межах групи тегів. Якщо allowedRelations групи містить "project", кожне визначення тут Є текою проєктів — саме цей інструмент її створює. Запис. |
Clients_create
Інструменти
| clients_create | Створити новий запис клієнта (обов'язкові name, country, currency, status, tinType). Запис. |
Clients_update
Інструменти
| clients_update | Оновити запис клієнта за id. Запис. |
Client Contacts_create
Інструменти
| clientContacts_create | Створити контактну особу для клієнта (обов'язкові client, type, name, email). Запис. |
Bank Accounts_create
Інструменти
| bankAccounts_create | Створити банківський рахунок (обов'язкові type, name, currency, defaultImportFormat). Запис. |
Bank Accounts_update
Інструменти
| bankAccounts_update | Оновити банківський рахунок за id. Запис. |
Banks_create
Інструменти
| banks_create | Створити банк — установу, якій належить банківський рахунок, а не сам рахунок (це bankAccounts_create). Запис. |
Banks_update
Інструменти
| banks_update | Оновити банк за id. Це також спосіб приховати і повернути банк: встановіть `hidden` true, щоб вивести його із селекторів без видалення, false — щоб повернути назад. Окремого інструменту архівування немає, бо API не має дії архівування для банку — прапорець і є механізмом. Запис. |
Counterparty Bank Accounts_create
Інструменти
| counterpartyBankAccounts_create | Прикріпити банківський рахунок до контрагента (counterparty + accountNumber). Запис. |
Contracts_create
Інструменти
| contracts_create | Створити договір. Запис. |
Contracts_update
Інструменти
| contracts_update | Оновити договір за id. Запис. |
Contracts_delete
Інструменти
| contracts_delete | Видалити договір за id. Запис. |
Tax Groups_create
Інструменти
| taxGroups_create | Створити податкову групу (обов'язкові name і type). Запис. |
Tax Groups_update
Інструменти
| taxGroups_update | Оновити назву або тип податкової групи за id. Запис. |
Tax Rules_create
Інструменти
| taxRules_create | Створити податкове правило. Запис. |
Tax Rules_update
Інструменти
| taxRules_update | Оновити податкове правило за id. Запис. |
Configs_update
Інструменти
| configs_update | Оновити значення конфігурації організації за id (обов'язкові type і name; дозволи перевіряються бекендом окремо для кожного ключа). Запис. |
Organization Addresses_update
Інструменти
| organizationAddresses_update | Оновити запис адреси ПІДПИСКИ організації (id обов'язковий; надсилайте лише поля, які змінюєте). САМЕ З ЦЬОГО ЗАПИСУ РЕНДЕРИТЬСЯ ПІДВАЛ ЛИСТА: {{organizationAddress}} підвалу складається як "street, postCode city" звідси, а НЕ з конфіг-ключів organization-billing-*, які рахунки-фактури та KSeF використовують як адресу продавця. Ці два сховища розходяться, і те, що підвал читає саме це, — відомий дефект: тож коли підпис показує адресу, яку клієнт клянеться, що виправив, він насправді виправив billing-ключі, а цей запис досі містить старе значення. `street` — це одна вільнотекстова колонка, яка має нести й номер будівлі: пошук за NIP/GUS заповнює лише назву вулиці і тихо відкидає номер будівлі й квартири, тому адреси тут читаються як "ul. Example" без номера. Запишіть повне "ul. Example 8/12", щоб виправити це. СПОЧАТКУ ПРОЧИТАЙТЕ через organizationAddresses_list і порівняйте з configs_get на organization-billing-street перед записом, щоб скопіювати власне підтримуване значення клієнта, а не вигадувати нове. Потребує ROLE_BILLINGS_MANAGER. Запис. |
Permission Groups_create
Інструменти
| permissionGroups_create | Створити групу дозволів (обов'язковий name; roles — список рядків ROLE_*, які вона надає). Запис. |
Permission Groups_update
Інструменти
| permissionGroups_update | Оновити назву, опис або надані ролі групи дозволів за id. Запис. |
People_invite
Інструменти
| people_invite | Дати наявній людині ЛОГІН: створює запрошення до організації, що очікує підтвердження, і надсилає його на пошту мовою UI, налаштованою в організації. Це той крок, якого НЕ роблять people_create і people_setPermissionGroups — людина з групами дозволів досі не може увійти, доки її не запрошено і вона не прийме запрошення. Потребує email людини; провалюється, якщо в неї вже є логін. Порядок онбордингу: people_create (запис) -> people_invite (логін) -> people_setPermissionGroups (права). Запис. |
People_set Permission Groups
Інструменти
| people_setPermissionGroups | Встановити (замінити) ЦІЛИЙ набір груп дозволів людини за числовими id груп (див. permissionGroups_list — напр., група "Business Owner" надає ROLE_ADMIN): передайте всі групи, у яких вона має опинитися, а [] прибирає їх усі. Надає доступ; НЕ створює логін і не надсилає лист людині — це people_invite. ПАСТКА: коли людині надають її ПЕРШУ групу, вона переходить на обчислювану модель, де ролі походять від груп і персональних перевизначень, і роль, надана їй вручну поза цією моделлю, зникає в тому самому виклику — ROLE_ADMIN, виданий одній людині напряму, — точно той різновид, який це прибирає. Працює й у зворотний бік: прибирання останньої групи повертає людину поза цю модель і змушує ті старі ролі з'явитися знову. Списки overridesAdded/overridesRemoved нічого про це не кажуть; вони описують перевизначення і лишаються порожніми, поки фактичний доступ змінюється. Тож відповідь повідомляє різницю між ролями, які людина мала до цього виклику і після нього, як rolesLost і rolesGained — саме цю пару варто прочитати, коли виклик повернеться. rolesLost null (не []) означає, що знімок, зроблений перед записом, прочитати не вдалося, і різниця НЕВІДОМА, з причиною в roleDeltaUnavailable: the… |
People_set Role Overrides
Інструменти
| people_setRoleOverrides | Встановити (замінити) ролі, які ОДНА людина отримує на додаток до — або замість — своїх груп дозволів. Спочатку звертайтеся до групи (people_setPermissionGroups): групи — це задумана абстракція, яка масштабується на більше ніж одну людину, тож використовуйте перевизначення лише там, де одна конкретна людина справді відрізняється від будь-якої групи. ЗАМІНЮЄ обидва списки цілком, тож спочатку прочитайте people_getPermissions і передайте назад кожне перевизначення, яке має залишитися; пропуск списку очищає його. Ролі — це константи ROLE_ — permissionGroups_list показує ті, які ця організація вже використовує. Роль, наявна і в added, і в removed, відхиляється, а не вгадується. Повертає той самий розв'язаний знімок, що й people_getPermissions, тож можна підтвердити результат без другого виклику. НЕ створює логін — див. people_invite. Потребує ROLE_ROLES_MANAGER. Запис. |
Holiday Days Limits_create
Інструменти
| holidayDaysLimits_create | Надати людині нарахування одного типу відпустки, чинне з дати. `seconds`, А НЕ дні (#3763): 8-годинний день це 28800, тож 21 день — це 604800, а баланс понаднормових 2г30хв — це 9000 — число, якому не було куди подітися, поки це зберігалося у цілих днях. `employee` і `holidayType` — це IRI (їх надають people_list і holidayTypes_list); `variant` — тип договору, до якого належить нарахування (uop, b2b, uz, uod). Щоб ВИПРАВИТИ наявний баланс, додайте рядок з пізнішою dateFrom замість редагування старого — чинний рядок це останній, чия dateFrom уже настала, тож історія лишається цілою, а виправлення можна ввести заздалегідь, до набуття чинності. (employee, holidayType, variant, dateFrom) унікальні, тож повторне надсилання того самого дня нічого не замінює і провалюється. Потребує ROLE_HOLIDAYS_MANAGER. Запис. |
Holiday Days Limits_update
Інструменти
| holidayDaysLimits_update | Виправити рядок, введений неправильно — друкарську помилку в сумі, неправильний variant. Суми в СЕКУНДАХ (#3763). Це НЕ спосіб фіксувати ЗМІНУ балансу з часом: для цього використовуйте holidayDaysLimits_create з новим рядком і пізнішою dateFrom, що зберігає, яким був попередній баланс і коли. Редагування на місці переписує історію і робить стару цифру непоновлюваною. holidayDaysLimits_list знаходить id. Потребує ROLE_HOLIDAYS_MANAGER. Запис. |
Holiday Requests_cancel
Інструменти
| holidayRequests_cancel | Скасувати заявку на відпустку — використовуйте, щоб прибрати заявку, за якою ніколи не мають діяти, наприклад рядок, залишений пробним періодом, тестом або людиною, яка звільнилася. ДВІ РЕЧІ, ЩО ЗДИВУЮТЬ. (1) ЦЕ НЕ ВИДАЛЯЄ РЯДОК: бекенд встановлює status у `canceled`, а не видаляє рядок. АЛЕ СКАСОВАНА ЗАЯВКА ЗНИКАЄ З holidayRequests_list — перевірено на продакшені: після цього ні нефільтрований список, ні status=canceled її не повертають. Тож прочитати назад те, що ви скасували, неможливо, і скасувати через MCP скасування не можна; переконайтеся в правильності id перед викликом. (2) ЦЕ НЕ ТЕ САМЕ, ЩО ВІДХИЛИТИ. Відхилення фіксує рішення — воно записує запис у журналі погоджень з вашим іменем і НАДСИЛАЄ ЛИСТ СПІВРОБІТНИКУ про те, що його відпустку відхилено — тоді як скасування повідомляє лише HR, і лише коли для організації увімкнено `notify-hr-managers-of-leave-activity`. Для рядка, який ніколи не був справжньою заявкою, скасування — чесніший і тихіший варіант. ПРАЦЮЄ ЛИШЕ НА ЗАЯВЦІ В СТАНІ ОЧІКУВАННЯ (`requested`), коли ви не є її власником: прийнята заявка вже створила Holiday, яку це не видаляє, тож скасування залишило б заброньовану відсутність позаду заявки зі статусом `canceled`. Потребує ROLE_HOLIDAYS_MANAGER для когось… |
Holidays_create
Інструменти
| holidays_create | Зафіксувати відпустку, яку людина фактично бере — саму заброньовану відсутність, а не право на неї (holidayDaysLimits_create) і не заявку, що очікує (заявки на відпустку, які ще треба погодити). Те, що записує цей інструмент, це вже узгоджений час відпочинку, тож він одразу з'являється в holidays_list і не потребує кроку погодження. `employee` — це IRI з people_list; `type` — id з holidayTypes_list. `dateFrom`/`dateTo` включно, і один виклик покриває цілий діапазон, а не рядок на день. Дві речі кусаються: тип, чий `descriptionRequired` є true (спочатку прочитайте holidayTypes_list — `vacations` зазвичай такий) ВІДХИЛЯЄ створення без `description`; а `pick-up-day` — це вже нарахований час, тож він НЕ витрачає річне нарахування так, як це робить `vacations` — подання дня, поверненого за суботнє державне свято, як `vacations` тихо з'їдає день чийогось права на відпустку. Перевірте holidays_list для тієї самої людини й дат перед створенням: цей endpoint охоче зафіксує ту саму відсутність двічі. КОЖНЕ СТВОРЕННЯ НАДСИЛАЄ ЛИСТ СПІВРОБІТНИКУ на його ж корпоративну адресу з повідомленням, що відсутність додано — тож завантаження року історії, яку людина вже прожила, приходить у її скриньку рядок за рядком, а для персоналу, який… |
Holidays_delete
Інструменти
| holidays_delete | Видалити заброньовану відсутність повністю — рядок видаляється, на відміну від holidayRequests_cancel, який лише змінює статус заявки. Використовуйте це, щоб прибрати відсутності, які ніколи не мали враховуватися: демо- чи тестові рядки, залишені пробним періодом, або осиротілі після видалення співробітника (people_delete відв'язує відсутності, а не видаляє їх, тож вони виживають з порожнім іменем співробітника). ЦЕ ЗМІНЮЄ РЕАЛЬНІ ЧИСЛА: заброньована відсутність — це `payrollEligible`, і вона витрачає право людини на відпустку, тож видалення однієї змінює її баланс відпустки — це і є суттю при очищенні тестових даних, і це баг втрати даних, коли рядок був справжнім. Без скасування, без сповіщення. Спочатку прочитайте holidays_list і переконайтеся, що рядок не є реальною історією: опис мовою самої організації або дати, що збігаються з реальною відсутністю, зазвичай означають, що є. Потребує ROLE_HOLIDAYS_MANAGER. Запис. |
Holiday Types_create
Інструменти
| holidayTypes_create | Додати тип відпустки, якого організація ще не пропонує — творчу відпустку, неоплачувану відпустку по догляду, день навчання — щоб можна було бронювати відсутності проти нього через holidays_create і надавати нарахування через holidayDaysLimits_create. `name` (3–64 символи) — це те, з чого обирають люди при бронюванні; `color` і `icon` — як це виглядає в календарі; `reducesWorkingTime` false позначає час відпочинку, який НЕ зменшує очікувані години місяця; а `descriptionRequired` true змушує тип вимагати причину, яку потім забезпечує holidays_create — див. цей інструмент щодо того, що він відхиляє. `status` за замовчуванням `active`, тож тип, створений без роздумів, одразу пропонується всім. СПОЧАТКУ ПРОЧИТАЙТЕ holidayTypes_list: типи діють для всієї організації, і ВИДАЛЕННЯ НЕМАЄ — дублікат чи назву з друкарською помилкою можна лише знову приховати, встановивши status у inactive через holidayTypes_update, і він тим часом зберігає кожну відсутність, заброньовану проти нього. Потребує ROLE_HOLIDAYS_MANAGER. Запис. |
Holiday Types_update
Інструменти
| holidayTypes_update | Змінити тип відпустки, і насамперед УВІМКНУТИ ЙОГО ЗНОВУ. `status` перемикається між `active` і `inactive`, і неактивний тип відхиляється holidays_create — тож фіксація історичної відпустки проти типу, який організація з того часу вивела з обігу, починається тут, і саме це розблоковує імпорт історії відпусток, а не відправляє когось у UI застосунку. ДЕАКТИВАЦІЯ — НЕ ВИДАЛЕННЯ, і видалення немає: уже заброньовані відсутності зберігають неактивний тип і досі читаються з ним у holidays_list, тож inactive означає лише "не пропонується для нових бронювань". ПАСТКА, ЩО З ЦЬОГО ВИПЛИВАЄ: реактивуйте `vacations`, щоб завантажити відсутності за минулий рік, забудьте повернути його назад в `inactive`, і ви не просто завершили імпорт — ви змінили те, що організація пропонує сьогодні, бо кожен співробітник, що бронює відпустку, тепер знову бачить цей тип у списку. Поверніть назад у тій самій сесії, у якій імпортували. `descriptionRequired` також впливає на holidays_create, який відхиляє бронювання без опису, щойно його увімкнено; увімкнення не чіпає вже записані відсутності. `id` — це рядковий id з holidayTypes_list (`vacations`, `not-paid`), і змінюються лише надіслані поля. Потребує ROLE_HOLIDAYS_MANAGER. Запис. |
Projects_create
Інструменти
| projects_create | Створити проєкт (обов'язкові name і type; type = fixed-price|time-and-material|non-billable|internal; необов'язкові dateFrom/dateTo, client, publicDescription, notes, priceNet). Запис. |
Projects_update
Інструменти
| projects_update | Оновити проєкт за id (name, type, дати, опис тощо). Запис. |
Project Members_create
Інструменти
| projectMembers_create | Додати людину НА проєкт (employee + project IRI обов'язкові, напр. "/people/204" і "/projects/243"; необов'язковий position = employee|tech-lead|account-manager|viewer, за замовчуванням employee). ЦЕ Й Є КОНТРОЛЬ ДОСТУПУ, а не мітка: людина, яка не є учасником, взагалі не бачить проєкт — він відсутній у її списку Projects, і вона не може логувати на нього час — тож це інструмент, що повертає доступ комусь, заблокованому поза проєктом. POSITION — НЕ КОСМЕТИКА: користувач з роллю, обмеженою проєктом, бачить лише ті проєкти, де його position членства збігається з роллю — ROLE_PROJECTS_LEAD збігається з tech-lead, ROLE_PROJECTS_VIEWER — з viewer — тож надання керівнику проєкту рядка `employee` лишає його таким же сліпим, як і без рядка взагалі. Членство НЕ каскадується: додавання людини до батьківської папки не дає їй нічого на проєктах під нею, тож дерево папок потребує одного виклику на проєкт. Унікальний ключ — (employee, project, position), тобто позиції складаються, а не замінюють одна одну — людина може мати employee ТА tech-lead на тому самому проєкті як два окремі рядки, і додавання tech-lead комусь, хто вже employee там, не видаляє й не підвищує рядок employee (використовуйте… |
Project Members_update
Інструменти
| projectMembers_update | Змінити position наявного членства за id (employee|tech-lead|account-manager|viewer) — отримайте id з projectMembers_list або з масиву projectMembers у projects_get. Використовуйте це, щоб підвищити чи понизити НА МІСЦІ; використовуйте projectMembers_create, щоб додати другу, додаткову позицію поряд з уже наявною. Зміна позиції може ВІДІБРАТИ видимість проєкту в когось, чия роль обмежена проєктом (ROLE_PROJECTS_LEAD, понижений з tech-lead до employee, перестає його бачити). Не можна перенести членство на іншу людину чи проєкт — для цього видаліть і створіть заново. Потребує ROLE_PROJECTS_MANAGER. Запис. |
Project Members_delete
Інструменти
| projectMembers_delete | Забрати людину З проєкту за id членства — знайдіть його через projectMembers_list або в масиві projectMembers у projects_get. ЦЕ ВІДБИРАЄ ДОСТУП: щойно зникає останній рядок членства цієї людини на цьому проєкті, проєкт зникає з її поля зору, і вона більше не може логувати на нього час — саме так проєкт тихо зникає для когось. Уже залоговані години НЕ видаляються і лишаються на проєкті; людина просто більше не може їх бачити чи додавати нові. Видалення однієї позиції лишає незмінною будь-яку іншу позицію, яку та сама людина має на тому самому проєкті. Потребує ROLE_PROJECTS_MANAGER. Незворотно (повторне створення робить новий рядок і знову сповіщає), значний вплив. Запис. |
Project Templates_create
Інструменти
| projectTemplates_create | Створити придатний до повторного використання шаблон проєкту з документа структури (version, project, phases та їхні lists/tasks). Зсуви всередині нього ВІДНОСНІ — startOffsetDays і durationDays рахуються в днях від startDate, заданої під час інстанціювання, тож один шаблон обслуговує кожен майбутній старт. project.name у структурі — це заповнювач; перевизначайте його для кожного клієнта під час інстанціювання. Структура валідується на сервері за схемою для заявленої версії, а порушення називає JSON-покажчик, що спричинив помилку. Запис. |
Project Templates_update
Інструменти
| projectTemplates_update | Оновити шаблон проєкту за id. Колонка структури зберігається і замінюється ЦІЛКОМ, ніколи не зливається — надішліть повний документ, інакше пропущені частини зникнуть. Спочатку прочитайте поточний через projectTemplates_get. Зміна шаблону НЕ зачіпає проєкти, вже інстанційовані з нього; зворотного поширення немає. Запис. |
Project Templates_delete
Інструменти
| projectTemplates_delete | Видалити шаблон проєкту за id. М'яке видалення, і воно НЕ зачіпає проєкти, вже створені з шаблону — це звичайні проєкти, і вони продовжують існувати. Запис. |
Project Templates_instantiate
Інструменти
| projectTemplates_instantiate | Побудувати реальний проєкт із шаблону — проєкт, його фази, списки завдань і кожне завдання, ОДНИМ атомарним викликом. startDate обов'язкова і є якорем, відносно якого розв'язується кожна startOffsetDays у шаблоні. Передайте name, щоб перевизначити заповнювач назви проєкту з шаблону, і client, щоб прив'язати новий проєкт до клієнта: подвійне інстанціювання проти ТОГО САМОГО клієнта — це те, як один клієнт зрештою тримає кілька угод, кожну як окремий проєкт. Повертає створений проєкт. Запис. |
Projects_archive
Інструменти
| projects_archive | Архівує проєкт за id — спосіб вивести з обігу проєкт, який не можна видалити, бо до нього прив'язані облік часу, рахунки або бюджети. Оборотно через projects_unarchive. Краще, ніж зсув dateTo назад, який лише створює вигляд завершеного проєкту. Запис. |
Projects_unarchive
Інструменти
| projects_unarchive | Відновлює заархівований проєкт за id, скасовуючи projects_archive. Запис. |
Responsibility Groups_create
Інструменти
| responsibilityGroups_create | Створення групи відповідальності / зони RACI (name обов'язкове; description і responsibleEmployee — відповідальна особа, задана як звичайний employee id, наприклад 6 (з people_list), або IRI /people/6 — необов'язкові). Це елемент верхнього рівня 'Odpowiedzialności'. Додавайте окремі відповідальності під нього через responsibilities_create. Запис. |
Responsibility Groups_update
Інструменти
| responsibilityGroups_update | Оновити групу відповідальності за id (name, description, responsibleEmployee — id співробітника або IRI). Запис. |
Responsibilities_create
Інструменти
| responsibilities_create | Створення відповідальності всередині групи (responsibilityGroup — id або IRI групи, + name, обов'язкові; description необов'язкове; parent — IRI іншої відповідальності для вкладеності, необов'язкове). Призначайте людей до неї через responsibilityEmployees_create. Запис. |
Responsibilities_update
Інструменти
| responsibilities_update | Оновити відповідальність за id (name, description, parent, responsibilityGroup — id групи або IRI). Запис. |
Responsibility Employees_create
Інструменти
| responsibilityEmployees_create | Призначити співробітника на відповідальність (обов'язкові responsibility — id відповідальності або IRI, employee — id співробітника або IRI, percentage 0-100; необов'язкові targets і description). Запис. |
Responsibility Employees_update
Інструменти
| responsibilityEmployees_update | Оновити призначення відповідальності за id (percentage, targets, description). Запис. |
Responsibility Employees_delete
Інструменти
| responsibilityEmployees_delete | Прибрати призначення співробітника з відповідальності за id. Запис. |
Leads_create
Інструменти
| leads_create | Створити ліда (ціль зовнішнього/вхідного пошуку; companyName, source, owner, пов'язаний client необов'язково). Новий лід завжди status=open — status тут не задається і рухається лише через leads_convert, leads_lose і leads_reopen. Запис. |
Leads_update
Інструменти
| leads_update | Оновити ліда за id (company, website, source, owner, пов'язаний client, stage, doNotContact). НЕ status чи lostReason: їх відхиляє сутність, і цей endpoint їх тихо ігнорує, тож закриття ліда потребує leads_lose (з lostReasonId), а скасування цього — leads_reopen. Переміщення `stage` проводить лідом лійку продажів; це не закриває ліда. Запис. |
Leads_delete
Інструменти
| leads_delete | Видалити ліда за id (м'яке видалення). Запис. |
Leads_convert
Інструменти
| leads_convert | Конвертувати кваліфікованого ліда в Client + по одному контакту на кожен lead-contact + відкриту Deal. Вимагає наявного клієнта (client ліда або clientId у тілі запиту). Запис. |
Leads_lose
Інструменти
| leads_lose | Закрити ліда як ВТРАЧЕНОГО — встановлює status=lost і фіксує closedAt. ПОТРЕБУЄ lostReasonId — `id` запису leadLostReasons (спочатку запустіть leadLostReasons_list; це список вибору, тож довільний текст відхиляється з 422). Це ЄДИНИЙ спосіб зафіксувати ліда як втраченого: leads_update ігнорує status, а doNotContact означає "більше ніколи не контактувати", що є інакшим і значно сильнішим твердженням, ніж "ми цю угоду не виграли". Це НЕ переміщує stage ліда — LeadStage не має термінального прапорця, тож лід зберігає свою позицію в лійці, а leads_reopen може відновити її точно. Запис. |
Leads_reopen
Інструменти
| leads_reopen | Скасувати дію leads_lose — повертає status назад у open і очищає closedAt та причину втрати. stage лишається незмінним, тож лід відновлюється точно там, де був. Звертайтеся до цього, коли ліда закрили проти неправильного запису або потенційний клієнт повернувся. Запис. |
Lead Activities_create
Інструменти
| leadActivities_create | Запис ОДНОГО контакту залучення для ліда — надіслане запрошення, прийняте запрошення, повідомлення, відповідь, дзвінок, подальший контакт (lead + type + occurredAt обов'язкові; channel, contact, body необов'язкові). Саме СЮДИ належить історія залучення потенційного клієнта: crmNote — довільний коментар, а активність — структурований, придатний для фільтрації журнал контактів, який відображає хронологія черги залучення. НЕ описуйте контакти в нотатці. type: invite_sent | invite_accepted | message_sent | reply_received | call | meeting | follow_up | …; channel: linkedin | email | phone | …. Запис. |
Lead Activities_update
Інструменти
| leadActivities_update | Оновлення зафіксованої активності залучення за id (type, channel, occurredAt, body). Запис. |
Lead Activities_delete
Інструменти
| leadActivities_delete | Видалення зафіксованої активності залучення за id. Запис. |
Lead Contacts_create
Інструменти
| leadContacts_create | Додавання контактної особи до ліда (lead + name обов'язкові; email, phone, role, linkedinUrl, isPrimary необов'язкові). URL LinkedIn контакту належить у linkedinUrl, а НЕ в crmNote. Запис. |
Lead Contacts_update
Інструменти
| leadContacts_update | Оновлення контакту ліда за id — наприклад, встановлення linkedinUrl / email / phone, щойно ви їх знайдете. Запис. |
Lead Contacts_delete
Інструменти
| leadContacts_delete | Видалити контакт ліда за id. Запис. |
Deals_create
Інструменти
| deals_create | Створити угоду/можливість. Обов'язкові: title, stage (з stages_list) і ЯКІР — принаймні один з client або lead. Угода без жодного відхиляється з 422 "A deal must reference a client or a lead.", тож прив'яжіть потенційного клієнта, для якого немає запису клієнта, до його ліда (`/leads/<id>` з leads_list), а не вигадуйте клієнта; передайте client (`/clients/<id>` з clients_list), щойно він з'явиться. Задати обидва дозволено. Необов'язкові: amountMinor, currency, expectedCloseDate, owner, contact. Створення одразу в стадії "виграно" додатково потребує client — угоду, прив'язану лише до ліда, не можна виграти. Запис. |
Deals_update
Інструменти
| deals_update | Оновити угоду за id (title, stage, amountMinor, currency, expectedCloseDate, owner, contact, client, lead). Переміщення stage логується автоматично. Правило якоря з deals_create досі застосовується до результату, тож не можна очистити єдиного client чи lead, які має угода — спочатку замініть один на інший. Переміщення угоди в стадію "виграно" потребує client: прив'яжіть клієнта тут (або запустіть leads_convert) перед виграшем угоди, прив'язаної лише до ліда. Запис. |
Deals_delete
Інструменти
| deals_delete | Видалити угоду за id (м'яке видалення). Запис. |
Deals_win
Інструменти
| deals_win | Позначити угоду виграною — переміщує її в стадію "виграно" і фіксує закриття; необов'язковий contractId прив'язує наявний договір. ДОВАНТАЖЕННЯ ІСТОРИЧНОГО ВИГРАШУ: передайте необов'язковий closedAt (ISO-8601, напр. "2026-05-07" або повний timestamp), щоб зафіксувати дату, коли угоду ФАКТИЧНО закрито. Пропустіть його — і сервер поставить позначку зараз, що потрапляє в цифру "виграно цього місяця" для старої угоди — тож встановлюйте його завжди, коли вводите угоду, закриту до сьогодні. Дата не може бути в майбутньому (422) і МОЖЕ бути раніше за власний createdAt угоди: угода, створена сьогодні й закрита в травні, — нормальна форма правильного довантаження, а не помилка. Угода вже МАЄ посилатися на client: виграш угоди, прив'язаної лише до ліда, відхиляється з 422 "Attach a customer before marking this deal Won.", бо нема кого виставляти рахунок. Перетворіть ліда на клієнта через leads_convert або встановіть client через deals_update, потім виграйте. Запис. |
Deals_lose
Інструменти
| deals_lose | Позначити угоду програною — потребує lostReasonId (з dealLostReasons_list); необов'язковий lostReasonNote. ДОВАНТАЖЕННЯ ІСТОРИЧНОЇ ПРОГРАШНОЇ УГОДИ: передайте необов'язковий closedAt (ISO-8601), щоб зафіксувати дату, коли угоду ФАКТИЧНО закрито, точно як це робить deals_win. Пропустіть його — і сервер поставить позначку зараз. Дата не може бути в майбутньому (422) і може бути раніше за createdAt угоди. Запис. |
Deals_reopen
Інструменти
| deals_reopen | Повернути виграну/втрачену угоду в статус open. Запис. |
Lead Lists_create
Інструменти
| leadLists_create | Створити список для вихідного пошуку клієнтів (обов'язковий name). Запис. |
Lead Lists_update
Інструменти
| leadLists_update | Оновити список для вихідного пошуку за id. Запис. |
Lead Lists_delete
Інструменти
| leadLists_delete | Видалити список для вихідного пошуку за id. Запис. |
Lead List Memberships_create
Інструменти
| leadListMemberships_create | Додати ліда до списку для зовнішнього прозвону (list + lead обов'язкові; status необов'язково). Будь-який переданий lastContactedAt — це знімок, який ніщо потім не просуватиме — також зафіксуйте контакт як активність ліда, інакше він лишиться недоступним для запитів. Запис. |
Lead List Memberships_update
Інструменти
| leadListMemberships_update | Оновити членство ліда в списку — напр., встановити статус прозвону (contacted/replied/bounced). status і lastContactedAt підтримуються викликачем: те, що ви записали, стоїть, доки хтось не запише знову, а фіксація активностей ліда НЕ оновлює їх. Запис. |
Lead List Memberships_delete
Інструменти
| leadListMemberships_delete | Прибрати ліда зі списку для вихідного пошуку. Запис. |
Work Times_update
Інструменти
| workTimes_update | Виправити один залогований запис робочого часу за id — його date, minutes, project або description. Саме так неправильно поданий запис ПЕРЕНОСЯТЬ між проєктами: workTimes_log лише створює, тож без цього інструменту неправильний проєкт чи друкарська помилка в описі назавжди. Спочатку прочитайте запис через workTimes_get. Та сама перевірка на занадто короткий опис діє, як і в workTimes_log: приблизно 32 символи — межа є налаштуванням на рівні організації і може бути 0, що вимикає перевірку — АБО посилання на тікет з "#", АБО http(s)-посилання, досить будь-чого одного з трьох. Запис. |
Work Times_delete
Інструменти
| workTimes_delete | Видалити один залогований запис робочого часу за id. Для дубліката чи запису, залогованого проти роботи, якої ніколи не було — надавайте перевагу workTimes_update, коли запис реальний, але неправильний, щоб години лишалися в записі, а не зникали з нього. Залоговані години живлять фінанси проєкту та утилізацію, тож видалення тихо змінює звітні числа за минулий період. Запис. |
Payment Schedule Lines_import
Інструменти
| paymentScheduleLines_import | Завантажити весь план внесків договору одним викликом замість одного запиту на рядок. Створено для девелоперських договорів, які оплачуються будівельними траншами — один продаж це шість-дванадцять внесків, а реєстр їх — сотні. Кожен рядок називає свій договір ЗА ІМЕНЕМ (для імпортованого девелоперського договору — це номер угоди), дату платежу та суму в МІНІМАЛЬНИХ ОДИНИЦЯХ — грошах, тож 5 300,00 це "530000", а "5300" тихо запише 53,00. Рядки узгоджуються з уже наявними лініями за контрактом+датою+сумою+нотатками, тож невідома лінія створюється, ідентична пропускається, і повторний запуск того самого пакета нічого не змінює; PaymentScheduleLine не має колонки зовнішнього посилання, тож саме цей природний ключ і є ключем узгодження. Рядок, чиє ім'я договору не збігається ні з чим, або збігається з БІЛЬШ НІЖ одним договором, звітується як провалений, а не прив'язується до здогадки — розміщення внеску на неправильному договорі спотворює одразу два грошові потоки. Спочатку передайте dryRun:true для реального завантаження. Максимум 1000 рядків. Запис. |
Payment Schedule Lines_create
Інструменти
| paymentScheduleLines_create | Додати один внесок до графіка платежів договору — план того, що очікується виставити чи сплатити, і коли. Передайте IRI договору, дату та суму. Саме це закриває проблему відсутнього графіка платежів, яку contracts_get звітує для нециклічного договору: одноразова оплата все одно має графік, це просто одна лінія на всю суму в день, коли вона настає. Циклічні договори на це не перевіряють, бо система не генерує лінії з періодичності автоматично. СУМА В МІНІМАЛЬНИХ ОДИНИЦЯХ — грошах, не злотих: 5 300,00 це "530000", а "5300" тихо запише лінію на 53,00. API повертає їх так само, тож прочитайте одну назад через contracts_paymentScheduleLines, якщо не впевнені в масштабі. Прочитайте результат назад через contracts_paymentScheduleLines. Запис. |
Payment Schedule Lines_update
Інструменти
| paymentScheduleLines_update | Змінити одну лінію графіка платежів за id — її date, amount або note. Використовуйте це, коли внесок зсувається чи перегоджується, замість видалення й повторного створення, щоб лінія зберігала будь-який уже зіставлений рахунок. СУМА В МІНІМАЛЬНИХ ОДИНИЦЯХ — грошах, не злотих: 5 300,00 це "530000", а "5300" тихо запише лінію на 53,00. API повертає їх так само, тож прочитайте одну назад через contracts_paymentScheduleLines, якщо не впевнені в масштабі. Запис. |
Payment Schedule Lines_delete
Інструменти
| paymentScheduleLines_delete | Видалити одну лінію графіка платежів за id. Видаляє ПЛАН, а не гроші: рахунок чи транзакція, вже зіставлені з лінією, не зачіпаються, але вона перестає бути з чимось узгодженою. Надавайте перевагу paymentScheduleLines_update для внеску, що змістився. Запис. |
CRM Notes_create
Інструменти
| crmNotes_create | Додати нотатку до ліда або угоди (обов'язкові body і рівно одне з lead/deal). Автор — підключений користувач. Запис. |
CRM Notes_update
Інструменти
| crmNotes_update | Оновити текст нотатки CRM за id. Запис. |
CRM Notes_delete
Інструменти
| crmNotes_delete | Видалити нотатку CRM за id. Запис. |
Organization Logo_upload
Інструменти
| organizationLogo_upload | Завантаження/заміна логотипа організації (зображення base64 + contentType + filename). Прочитайте поточний через configs_get organization-logo-url. Запис. |
Organization Icon_upload
Інструменти
| organizationIcon_upload | Завантаження/заміна іконки/фавікону організації (зображення base64 + contentType + filename). Прочитайте поточну через configs_get organization-icon-url. Запис. |
Storage_upload
Інструменти
| storage_upload | Прикріпити файл до будь-якого запису, який приймає загальне сховище Flowtly — АКТИВ (relationName "property"), проєкт, завдання, клієнт, локація, підрядник, рахунок-фактура, HR-запис. Це єдиний шлях до ЗОБРАЖЕННЯ активу: завантаження з relationName "property" встановлює зображення, яке застосунок показує для цього активу (подається як `file` у payload активу). Property не має колонки зображення — зображення виводиться з цієї таблиці під час читання, тому нічого в сутності не натякає на його існування. Це ОДИН слот, і найновіше завантаження перемагає, тож друге зображення замінює перше, а не додається до галереї; обидва рядки лишаються в списку під /assets/{id}/documents. Те саме стосується location, invoices і transaction-attachments; clients, agreements і candidates натомість накопичують кожне завантаження під `files`; решта показуються лише на своєму маршруті /documents. `file` пропускається у відповідях LIST, якщо запит не передає ?include=file, тож прочитайте один запис назад, щоб підтвердити, що зображення потрапило. Передайте relationName + relationId (id з інструменту списку цього запису; IRI /assets/7 приймається і скорочується) плюс байти як base64 з contentType і filename. ОБМЕЖЕННЯ РОЗМІРУ: байти передаються як base64 усередині… |
Storage_create Upload Ticket
Інструменти
| storage_createUploadTicket | Видати короткочасний одноразовий квиток для прикріплення ВЕЛИКОГО файлу до будь-якого запису — саме так зображення активів реально потрапляють у систему, бо зображення завжди перевищує стелю base64. На property/location/invoices/transaction-attachments найновіше завантаження стає видимим зображенням запису, замінюючи попереднє; на clients/agreements/candidates завантаження накопичуються. Використовуйте це замість storage_upload щоразу, коли файл більший за кілька десятків КБ: той інструмент передає байти як base64, які викликач має видати як текст, а JPEG на 400 КБ стає ~533 К символів base64 — набагато більше, ніж вміщується в одну відповідь. Передайте relationName + relationId плюс filename; у відповідь отримаєте uploadUrl і готовий до запуску curl. Потім надішліть СИРІ БАЙТИ файлу на цю URL (curl --data-binary @photo.jpg) — не base64, не multipart — і відповідь міститиме створений запис Storage. Квиток спливає за 15 хвилин, працює один раз і може подати лише проти того одного запису, який названо. Запис. |
Contract Attachments_create
Інструменти
| contractAttachments_create | Прикріпити документ до договору — зазвичай підписаний PDF або додаток (DPA, SLA, ціновий додаток), поданий разом з ним. Передайте байти як base64 з fileName і id договору з contracts_list; `contractId` тут — ПРОСТИЙ id, на відміну від IRI, які contracts_update приймає для counterparty і project, хоча повний IRI /contracts/<id> також приймається й скорочується. ОБМЕЖЕННЯ РОЗМІРУ: байти передаються як base64 усередині цього виклику, тож увесь документ має вміститися в одну відповідь моделі — тримайте його під приблизно 150 КБ, а для чогось більшого використовуйте натомість contractAttachments_createUploadTicket, який створено саме для цього і не має такої стелі. Підписаний договір з карткою підпису зазвичай значно перевищує це (673 617 байт стають 898 156 символами base64, у кілька разів більше, ніж може нести одна відповідь), і жодної помилки не повертається, коли він не вміщується, бо виклик узагалі не може бути сформований — запит ніколи не досягає сервера, тож перевіряйте розмір файлу ПЕРЕД початком, а не дізнавайтеся про це через провал. Саме це закриває проблему відсутнього документа, яку звітує contracts_get, тож договір, що підтримується через API, перестає сидіти в черзі "потребує впорядкування" застосунку. Один підписаний документ може підтвердити… |
Contract Attachments_create Upload Ticket
Інструменти
| contractAttachments_createUploadTicket | Видати короткочасний одноразовий квиток для прикріплення ВЕЛИКОГО документа до договору — підписаного PDF або додатку. Використовуйте це замість contractAttachments_create щоразу, коли файл більший за кілька десятків КБ: той інструмент передає байти як base64, які викликач має видати як текст, а реальний підписаний договір (~700 КБ, ~900 К символів base64) значно перевищує те, що вміщується в одну відповідь. Передайте id договору з contracts_list плюс fileName; у відповідь отримаєте uploadUrl і готовий до запуску curl. Потім надішліть СИРІ БАЙТИ файлу на цю URL (curl --data-binary @file.pdf) — не base64, не multipart — і відповідь міститиме створене прикріплення. Квиток спливає за 15 хвилин, працює один раз і може прикріпити лише до того одного договору, який названо. Саме це закриває проблему відсутнього документа, яку звітує contracts_get. Запис. |
Incoming Invoices_create
Інструменти
| incomingInvoices_create | Внесення вхідного (постачальницького) рахунку або супровідного документа в бухгалтерію — передайте байти у форматі base64 з fileName і receivedAt. Flowtly розпізнає їх (OCR) і пропонує постачальника та відповідну банківську транзакцію. Файл має відбиток externalId 'upload_sha256:<sha256 байтів>': щоб уникнути дублікату, обчисліть хеш байтів і перевірте incomingInvoices_list на наявність цього externalId ПЕРЕД завантаженням. Запис. |
Invoices_export
Інструменти
| invoices_export | Запуск zip-експорту ВИСТАВЛЕНИХ рахунків за період (from/to, обидва у форматі YYYY-MM-DD, включно), відфільтрованих за ДАТОЮ ПРОДАЖУ — не датою виставлення й не датою створення. Включаються лише ВИСТАВЛЕНІ рахунки; чернетки та невідправлені рахунки виключаються, але коригування ВКЛЮЧАЮТЬСЯ. Необов'язковий client обмежує вибірку одним клієнтом (id або IRI з clients_list). Максимум 200 рахунків на експорт — якщо в періоді більше, звузьте його (наприклад, експортуйте по одному місяцю); період без жодного виставленого рахунку також відхиляється. Цей виклик лише додає завдання в чергу (формування за місяць може тривати хвилини) — він НЕ повертає посилання на завантаження. Опитуйте invoices_exportStatus з отриманим exportId, доки не з'явиться статус "ready". Запис. |
Invoices_export Status
Інструменти
| invoices_exportStatus | Опитування статусу zip-експорту, запущеного через invoices_export, за exportId. Коли статус "ready", відповідь містить downloadUrl (короткочасне підписане посилання — дійсне 1 годину, див. expiresAt), filename і byteSize; байти файлу через цей інструмент ніколи не повертаються. Якщо статус "failed", failureReason пояснює причину. |
Invoices_import
Інструменти
| invoices_import | Подати ВЖЕ ВИСТАВЛЕНИЙ вихідний (продажний) рахунок-фактуру в організацію — щоб перенести історію рахунків при онбордингу. Зовнішній номер рахунку, який ви передаєте, зберігається дослівно, покупця розв'язують за податковим ідентифікатором (створюють, якщо відсутній), і рахунок потрапляє в систему як виставлений БЕЗ рендерингу PDF, надсилання листа клієнту чи подання до KSeF. Імпорт номера, який уже існує, — це no-op, що повертає наявний рахунок, тож масовий імпорт безпечно повторювати — але ця гарантія діє лише для послідовних викликів; два справді одночасних імпорти того самого номера можуть обидва потрапити в систему. Передайте expectedGrossTotal (брутто, надрукований на вихідному документі), і імпорт буде відхилено, якщо він розходиться з підсумком, обчисленим з рядків. buyer.tin обов'язковий — покупця ніколи не зіставляють за іменем. Використовуйте invoices_create, а не це, щоб виставити справді новий рахунок. Запис. Передайте dryRun:true для ПОПЕРЕДНЬОГО ПЕРЕГЛЯДУ без запису — повідомляє would-create / would-skip і не створює ні рахунку, ні клієнта; спочатку прогоніть історичне довантаження в режимі dry і перевірте числа перед реальним запуском. |
Invoice Transactions_create
Інструменти
| invoiceTransactions_create | Реєстрація платежу за вихідним (продажним) рахунком. `invoice` — це IRI рахунку з invoices_list; `date` — дата, коли платіж вважається здійсненим. `transaction` необов'язковий — пропустіть його, щоб зафіксувати оплату без банківського рядка, що потрібно для історичних рахунків, банківську виписку за якими ніколи не імпортували. `amount` необов'язковий і за замовчуванням дорівнює непогашеній сумі рахунка. Реєстрація платежу — це те, що зупиняє трактування виставленого простроченого рахунка як несплаченого, а отже й те, що зупиняє постановку нагадувань про оплату в чергу. Ніщо не забороняє зареєструвати два платежі за одним рахунком, тож спершу прочитайте invoices_get, якщо не впевнені, чи рахунок уже погашено. Запис. |
Invoice Transactions_update
Інструменти
| invoiceTransactions_update | Оновлення наявного запису платежу за рахунком за id (з invoiceTransactions у invoices_get або через пагінацію invoiceTransactions). Найпоширеніше застосування: прив'язати платіж, зареєстрований без банківського рядка, до транзакції, щойно імпортованої через transactions_importStatement, встановивши `transaction` рівним IRI/id транзакції з transactions_list. ПАСТКА: це PATCH, але бекенд все одно вимагає `invoice` і `date` при кожному виклику — він НЕ підставляє наявні значення за вас. Спершу прочитайте запис (або вже майте його з виклику створення) і повторно надішліть незмінені `invoice` і `date` разом із тим, що ви справді хочете змінити, інакше оновлення буде відхилено. `transaction` приймає null, щоб відв'язати платіж від банківського рядка. `amount` необов'язковий. Запис. |
Invoice Transactions_delete
Інструменти
| invoiceTransactions_delete | Видаляє запис про платіж із рахунку за id — ідентифікатори візьміть з invoiceTransactions у invoices_get. Це прибирає ЗАПИС ПРО ТЕ, ЩО РАХУНОК БУЛО ОПЛАЧЕНО, а не банківську транзакцію: застосовуйте, коли рахунок несе платіж, якого ніколи не мало бути, найчастіше — той самий платіж, проведений двічі: раз вручну і раз імпортом виписки, який згодом його зіставив. Спершу перевірте invoices_get і видаліть той запис, чия `transaction` є хибною (залиште той, що вказує на справжній імпортований банківський рядок); видалення останнього платежу знову робить рахунок неоплаченим, що повторно вмикає для нього нагадування про оплату. Потребує ROLE_INVOICES_MANAGER. Незворотно, з великим впливом. Запис. |
Invoices_create
Інструменти
| invoices_create | Виставити НОВИЙ вихідний (продажний) рахунок-фактуру — інструмент для першого виставлення рахунку клієнту. Не плутайте з двома сусідніми: invoices_import довантажує рахунок, ВЖЕ виставлений деінде (історія онбордингу), а incomingInvoices_create подає видатковий документ постачальника. Рахунок потрапляє НЕВІДПРАВЛЕНИМ: status виводиться з рядків журналу рахунку, а свіжий рахунок їх не має, тож цей виклик нічого не рендерить, не надсилає листом і не подає до KSeF — вважайте результат чернеткою для перегляду перед виставленням. `name` — це номер рахунку, і ви обираєте його самі (макс. 32 символи) — спочатку прочитайте invoices_list і дотримуйтеся наявної серії організації, а не вигадуйте нову, бо ніщо тут не виділяє вам наступний номер автоматично. Обов'язкові: name, type ("invoice"), tinType, issueDate, saleDate, dueDate. Передайте `client` (IRI з clients_list) і, для бронювання, що узгоджується пізніше, `contract` (IRI з contracts_list), щоб рахунок з'явився під цим договором. Позиції йдуть у `invoiceRows` — чиста ціна за одиницю, кількість і ставка податку на рядок; підсумки обчислюються з рядків, а не передаються напряму. `bankAccount` (з bankAccounts_list) обирає рахунок, надрукований на документі, а `currency`… |
Invoices_update
Інструменти
| invoices_update | Виправити вихідний (продажний) рахунок-фактуру за id, до або після виставлення. Щоденне застосування — це виправлення чернетки, виставленої invoices_create — неправильної дати, неправильного рядка, відсутнього зв'язку з договором — а не видалення й повторне виставлення, що спалило б номер рахунку. Спочатку прочитайте invoices_get: це PATCH поверх документа, чиї підсумки виводяться з його рядків, тож заміна `invoiceRows` замінює весь набір, а рахунок, який уже надіслано, не скасує надсилання лише через те, що ви його відредагували. Запис. |
Incoming Invoices_apply Suggestion
Інструменти
| incomingInvoices_applySuggestion | Прийняття однієї з власних пропозицій Flowtly для вхідного рахунку — тих самих пропозицій, які людина бачить у застосунку (відповідність постачальника, група витрат, відповідна банківська транзакція, попередження про дублікат). Спершу прочитайте їх через incomingInvoices_suggestions, потім застосуйте одну за її id. Надавайте цьому перевагу над вгадуванням: саме алгоритм зіставлення Flowtly, а не агент, вирішує, що є правдоподібним. Запис. |
Incoming Invoices_accept All Suggestions
Інструменти
| incomingInvoices_acceptAllSuggestions | Прийняти всі очікувані пропозиції для вхідного рахунку одним викликом — те саме, що робить людина кнопкою "прийняти все" у застосунку. Сервер застосовує, перебудовує й застосовує знову, поки не перестануть з'являтися нові пропозиції: відповідність транзакції НЕ існує, доки не застосовано постачальника й суму, тож один прохід залишив би документ неприкріпленим. Повертає звіт (що застосовано, що відхилено і чому, та транзакцію, до якої зрештою прикріплено документ). Передайте dryRun для попереднього перегляду без запису. Ніколи не приймає автоматично supplier_create або попередження про дублікат. Запис. |
Incoming Invoices_check EInvoices
Інструменти
| incomingInvoices_checkEInvoices | Отримання нових електронних рахунків KSeF в організацію — те саме, що робить кнопка "Sprawdź e-faktury" в застосунку. Викликайте це перед тим, як робити висновок про відсутність рахунку постачальника: без цього неможливо відрізнити "постачальник ніколи не надсилав" від "наша синхронізація ще не запускалася". Повертає результат одразу після постановки отримання в чергу; після цього перечитайте incomingInvoices_list, щоб побачити, що надійшло. Запис. |
Resourcing_import Timeline
Інструменти
| resourcing_importTimeline | Імпорт таблиці хронології алокацій ресурсування (отримайте її через Drive MCP, передайте її CSV дослівно). Це ПОВНЕ ЗАМІЩЕННЯ рядків Allocation організації для `year`: рядки в таблиці створюються/оновлюються, а будь-який наявний рядок за цей рік, відсутній у таблиці, ВИДАЛЯЄТЬСЯ — це не злиття. ЗА ЗАМОВЧУВАННЯМ — ПРОБНИЙ ЗАПУСК: пропущений dryRun лише показує попередній перегляд і нічого не записує; передайте dryRun:false, щоб застосувати зміни. Звіт містить `created` / `replaced`, а також `unmatchedPeople` / `unmatchedProjects`. ДВІ РЕЧІ ЛЕГКО ПРОПУСТИТИ: рядок таблиці, проєкт якого не вдається розпізнати, ПРОПУСКАЄТЬСЯ, хоча виклик все одно повідомляє про успіх, тож позитивний результат може приховувати частковий імпорт; а код ролі, якого ще немає в каталозі позицій, СТВОРЮЄТЬСЯ як нова позиція, а не відхиляється — див. `createdPositions`. Обидва випадки зазначаються у `warnings`, коли трапляються; повідомляйте про це користувачу, а не звітуйте лише про `created`. Таблиця, що розпізнається як нуль рядків, відхиляється (це виглядає точно як помилка читання, що зараз стерла б усю хронологію), якщо не передати force:true. Після цього прочитайте allocations_list, щоб побачити, що потрапило в систему. Високий вплив. Запис. |
Transactions_import Statement
Інструменти
| transactions_importStatement | Імпорт файлу банківської виписки (наприклад, файлу MT940 .sta) — передайте сирий текстовий вміст кожного файлу дослівно (НЕ base64) із filename. ПАРАМЕТРА bankAccount НЕ ІСНУЄ: бекенд маршрутизує файл, видаляючи всі нецифрові символи з номерів ваших банківських рахунків та з байтів файлу, й імпортуючи в кожен рахунок, цифри якого зустрічаються будь-де у файлі — тож один файл може потрапити в кілька рахунків, а виписка для рахунку, який не налаштовано у Flowtly (або номер якого записано інакше, ніж пише банк), не імпортується в жоден із них, завершуючись помилкою, яка точно пояснює причину — читайте це повідомлення, це єдина діагностика, яку дає цей ендпоінт. У разі успіху відповідь має вигляд `{ imported, matching }`: `matching: "in_progress"` означає, що зіставлення контрагента/вкладення для нових рядків усе ще триває після завершення цього виклику, тож негайний запит transactions_list може показати рядки, які ще не зіставлені — перечитайте трохи пізніше для остаточного стану. Повторний імпорт тієї самої виписки не створює дублікатів рядків; імпортер розпізнає вже бачені транзакції. Коли виписку внесено, прив'яжіть наявний платіж без банківського рядка до одного з її рядків за допомогою… |
Transactions_delete
Інструменти
| transactions_delete | Видаляє банківську транзакцію за id — знайдіть її через transactions_list. Вдавайтеся до цього ЛИШЕ щоб виправити бухгалтерську помилку, яку неможливо усунути інакше: виписку, імпортовану на хибний банківський рахунок, або рядки, внесені вручну до надходження справжньої виписки і тепер нею продубльовані. Транзакція — це запис того, що зробив банк, тож її видалення на імпортованому рахунку призводить до розбіжності обліку з банком; бекенд дозволяє це лише для ROLE_ADMIN (менеджер транзакцій може видаляти тільки на готівкових та ручних рахунках). ПЕРЕД видаленням гаданого дубліката доведіть пару: зіставте імпортований рядок за сумою І номером рахунку І контрагентом, а не лише за сумою — платіж, що надійшов після кінцевої дати виписки, не має відповідника, і його видалення знищує єдиний слід цього доходу. Бекенд ВІДʼЄДНУЄ, а не видаляє те, що на ній тримається: платежі за рахунками лишаються з очищеним банківським рядком (перепризначте їх через invoiceTransactions_update), вкладення та обʼєкти нерухомості відвʼязуються, натомість рядки проєктних і працівницьких транзакцій зникають разом із нею. Незворотно, з великим впливом. Запис. |
Organization_whoami
Інструменти
| organization_whoami | Повертає організацію, до якої прив'язане це підключення MCP — { orgId, name, slug, userId }. Викликайте, щоб підтвердити, В ЯКОГО орендаря ви збираєтесь записувати дані перед будь-яким створенням/оновленням: підключення прив'язане рівно до однієї організації через токен, а запис потенційних клієнтів/записів у неправильну організацію — це реальний інцидент. Лише читання. |
Resourcing Actuals_get
Інструменти
| resourcingActuals_get | Звітовані години порівняно з планом, для кожної людини за тиждень, у межах вікна from/to — питання 'чи команда справді дотримується плану?', на яке НЕ відповідає жоден інший інструмент ресурсування: алокації повідомляють, що було ЗАПЛАНОВАНО, а це — що було ВИКОНАНО. Повертає стовпці по тижнях і по одному рядку на людину (плановий %, звітований %, відхилення, підсумки та розбивка за проєктами). reportedPercent null означає 'того тижня не було договору', а 0 означає 'договір був, але нічого не звітовано' — НЕ ототожнюйте ці два випадки. Передайте financials, щоб отримати дохід/витрати/маржу, які інакше пропускаються. Потребує модуля ресурсування та ROLE_RESOURCING_MANAGER. Лише читання. |
Resourcing Bench_get
Інструменти
| resourcingBench_get | Хто НЕ зайнятий у межах вікна from/to — резерв. Використовуйте, коли потрібно вирішити, кого поставити на новий проєкт або де потужність простоює; resourcingActuals_get повідомляє, наскільки завантажені люди, а це — хто взагалі не має завантаження. ЦЕЙ ІНСТРУМЕНТ НЕ ЗНАЄ ПРО ВІДПУСТКИ: freePercent — це 100 мінус підтверджені алокації, і нічого більше, тож людина на трьохтижневій схваленій відпустці показує 100% вільна, і жодне поле відповіді не вказує на протилежне. Відповідь на питання 'хто доступний' лише на основі цього поставить людей на проєкти, поки вони відсутні — перевіряйте також holidays_active або holidays_list. Потребує модуля ресурсування. Лише читання. |
Resourcing Schedule_get
Інструменти
| resourcingSchedule_get | Запланований графік ресурсування в межах вікна from/to — хронологія алокацій так, як її показує планувальник. Використовуйте, щоб дізнатися, що ЗАБРОНЬОВАНО на майбутнє; використовуйте resourcingActuals_get, щоб дізнатися, що фактично звітовано за цим. Потребує модуля ресурсування та ROLE_RESOURCING_MANAGER. Лише читання. |
People_get Permissions
Інструменти
| people_getPermissions | Що людина фактично може робити, розв'язано: її групи дозволів (кожна з ролями, які вона надає), її персональні перевизначення та effectiveRoles, у які поєднуються ці два. САМЕ ТАК перевіряють, чи набула чинності зміна доступу — people_list показує поле roles, але саме цей інструмент пояснює, ЧОМУ вона має ці ролі і який важіль потягнути, щоб це змінити. Звертайтеся сюди перед кожним викликом people_setRoleOverrides, бо той інструмент замінює списки перевизначень цілком, а тут ви читаєте поточні. staleOverrides — це видалені перевизначення, які більше не збігаються з жодною роллю, наданою групою, тож наразі вони нічого не роблять. people_list надає id. Потребує ROLE_ROLES_MANAGER для перегляду будь-кого, крім себе. Лише читання. |
Leads_bulk Import
Інструменти
| leads_bulkImport | Імпорт багатьох лідів за ОДИН виклик, кожен із вкладеними контактами, членством у списку та активностями залучення — сервер створює лід, а потім передає його id у дочірні елементи, тож вам не потрібно жонглювати проміжними IRI. Ідемпотентно за природними ключами (companyName / email / (list,lead) / (type,occurredAt,contact)): безпечно повторювати виклик і розбивати на частини (≤100 лідів за виклик). Це масовий шлях, який слід використовувати для імпорту кампанії замість N викликів leads_create. Запис. |
Lead Activities_by List
Інструменти
| leadActivities_byList | Кожна активність ліда для КАМПАНІЇ (списку лідів) одним викликом — передайте id, IRI або точне ім'я списку. leadActivities_list фільтрує за одним лідом, тож звітність на рівні кампанії інакше коштувала б одного виклику на учасника (302 для списку на кшталт PZFD); цей інструмент натомість розв'язує учасників списку і читає їхні активності обмеженими пакетами. Поєднуйте з type і occurredAt.after/.before, щоб отримати числа, які люди реально запитують: частка відповідей (type=reply_received), частка відмов (type=bounced), покриття розсилки (type=message_sent). Повертає listId, listName, leadCount і об'єднані активності, відсортовані за occurredAt. Невідомий список — це ПОМИЛКА, а не порожній результат — тож помилково введене ім'я не можна прочитати як "ця кампанія не мала активності". Id беруться з leadLists_list. Лише читання. |
Lead Activities_bulk Import
Інструменти
| leadActivities_bulkImport | Зафіксувати цілу хвилю зовнішніх повідомлень — кожне повідомлення, яке ви фактично надіслали — ОДНИМ викликом, замість одного leadActivities_create на повідомлення. Передайте масив; кожен рядок називає свого ліда (leadCompanyName, зіставлене з ІСНУЮЧИМ лідом, або IRI ліда) плюс type і occurredAt. Дайте кожному рядку externalId — стабільний id для кожного повідомлення, напр. id повідомлення Gmail — і імпорт стає ідемпотентним: повторний запуск, або повторний запуск хвилі, яку імпортовано лише частково, звітує дублікати замість того, щоб створювати їх. Рядки без externalId дедуплікуються за (lead, type, occurredAt, contact) — тим самим природним ключем, який використовує leads_bulkImport, тож хвиля, що вперше потрапила через той інструмент, тут не дублюється. Кожен рядок отримує власний outcome (created | duplicate | error), тож один неправильно сформований рядок не відкидає решту пакета. НЕ створює лідів — для цього використовуйте leads_bulkImport. ≤ 1000 рядків/виклик. Запис. |