Відповідь: Для авторизації потрібно передавати заголовок у форматі Bearer + APIkey.

"headers":{"authorization":["Bearer ваш-API-ключ"]}

Відповідь: В документації API описано кожен метод. Приклади запитів чи відповідей містять список усіх доступних параметрів для цього метода. 

На вкладці «Schema» детально описано кожен доступний параметр з вказанням типу даних і прикладом значення: 

Відповідь: Стандартний набір статусів створюється з аліасами в назвах - по ним підставляється в інтерфейсі відповідно до мови користувача назва статусу.

Вам достатньо перезберегти назви статусів в мові, щоб назви закріпились і стали відображатись в API.

Відповідь: Пропишіть дані до кожного поля через кому в масиві custom_fields.

Якщо поле з типом список або мультисписок, то список значень потрібно передавати у параметрі value в масиві. Усі значення мають бути додані, як опції в цьому полі. 

"custom_fields": [
    {
      "uuid": "системна назва поля з CRM",
      "value": "Значення, яке потрібно записати в це поле"
    },
    {
      "uuid": "системна назва поля з CRM",
      "value": ["Опція 1", "Опція 2", "Опція 3"] 
    }
  ]

Відповідь: За замовченням передаються тільки базові дані, щоб отримати усі доступні додаткові, додайте до запиту include, до кожного метода в документації додано список доступних.

Відповідь: В нас діє обмеження до 60 запитів на хвилину з однієї IP-адреси по API-ключу. Якщо частота запитів більше цього ліміту, запити починаються отримувати цю помилку. 

Рекомендуємо оптимізувати ваш процес, щоб знизити кількість запитів. Наприклад, ви можете налаштувати паузу між запитами в 1 секунду. 

Відповідь: В нашій документації немає можливості додати API ключ, відправляти запити та отримувати відповіді від сервера. Оскільки запит був би надісланий з браузера. Саме такі запити ми не обробляємо з цілей безпеки, тому що в такому випадку API токен буде у відкритому доступі, інші користувачі зможуть його отримати та за його допомогою отримати доступ до особистих даних або редагувати інформацію користувачів.

Ви можете тільки згенерувати приклади потрібних вам запитів для подальшого використання. І побачити там приклади відповідей і які дані ви можете отримати. А для перевірки запиту можна використовувати програми для роботи з API, наприклад POSTMAN.

Відповідь: Помилка означає, що в цьому джерелі вже є замовлення з цим номером з джерела (source_uuid). Відповідно повторно замовлення з таким самим номером створено не може бути, це перевірка системи на дублі.

Можливо видалялись замовлення на сайті чи відновлювали резервну копію (бекап). Оскільки вірогідно збилась нумерація на сайті та використані номери замовлень знову стали доступними для нових замовлень.

Відповідь: Скоріше за все ви передали ідентифікатор, якого не має в системі. В методі на оновлення залишків потрібно передавати саме offer_id - ідентифікатор варіанта товару, він не дорівнює product_id (ідентифікатор товару).

Навіть якщо у вас товари без варіантів, кожен з них має offer_id. Оскільки для системи товар без варіантів означає товар в одному варіанті. Ідентифікатори варіантів можна отримати у файлі експорту або запитом на отримання списку варіантів товарів по API. 

Якщо ви використовуєте артикули, то залишки можна оновлювати тільки передавши sku, без потреби отримувати та передавати ідентифікатори варіантів.

Відповідь: Перевірте основні моменти: 

• На вашому сервері коректний SSL сертифікат;
• Запити відправляються з сервера, а не з браузера;
• Ваш хостинг провайдер не блокує відправку запитів. 

Якщо ви все перевірили і складність залишається - напишіть в нашу підтримку. 

Відповідь: Поки що не усі зміни в замовленні оновлюють це поле, а саме зміни в полях:

• Теги;
  
• Відповідальні;
  
• ЮТМ-мітки;
  
• Файли;
  
• Завдання;
  
• Оплати;
  
• Тип відвантаження.
  

Зміни в усіх інших полях замовлення будуть оновлювати дату в "updated_at".

Відповідь: Щоб додати файл, спочатку його потрібно завантажити на сервер CRM. У відповіді ви отримаєте id (fileId) - ідентифікатор вашого файлу в системі. 

Далі вже можна передати запит на додавання цього файла у картку воронки чи у замовлення.

Відповідь: Як при отриманні загальних залишків по усім складам, так і при отриманні залишків по кожному складу окремо ви отримуєте кількість у двох полях:

1. «quantity» — загальна кількість залишків;
2. «reserve» — загальна кількість зарезервованих залишків.

Відповідно ви можете при отриманні додати формулу розрахунку в скрипт і від загального залишку віднімати резерв, щоб записувати саме кількість доступну до продажу з врахуванням резерву по товарам.

Відповідь: Помилка означає, що переданий email не валідний. Адреса електронної пошти має бути в форматі xxx@xxx.xxx без пробілів і спец.символів. Некоректні дані можуть спричинити додаткові проблеми, тому система перевіряє усі дані, які ви надсилаєте.

Рекомендуємо додати валідацію email на стороні вашого сайту, мобільного додатку чи іншої системи, яка передає дані через API. Це зменшить кількість помилок і забезпечить коректність контактної інформації. Також варто перевіряти дані на сервері для додаткового захисту від некоректного вводу.

Відповідь: Swagger дозволяє взаємодіяти з API через зручний веб-інтерфейс, де можна переглядати документацію та згенерувати приклади потрібних вам запитів для подальшого використання, побачити там приклади відповідей і які дані ви можете отримати:

• Перейдіть в нашу документацію API;
• Оберіть потрібний метод;
• Натисніть Try it out та заповніть параметри; 
• Натисніть Execute, щоб сформувати посилання, взяти curl та можна використовувати в програмі для роботи з API, наприклад POSTMAN чи зі свого сервера. 

Відповідь: 

• Фільтр created_between працює саме по даті створення в CRM ("created_at"), а не по даті створення на джерелі ("ordered_at"), яке може не збігатися з "created_at".  Тому перевірте чи вірні дати ви передаєте;
• Час у всіх сутностях використовується UTC (GMT+0), тому варто врахувати його при вказанні дати.

Відповідь:  Один з варіантів реалізації автоматичної зміни статусів замовлень із CRM на сайт:

1. На сайті додати скрипт, який отримуватиме та зберігатиме список статусів із CRM та прописати відповідність статусів між сайтом і CRM;

2. У CRM налаштувати тригер, який автоматично відправлятиме вебхук при зміні статусу замовлення;

3. Реалізувати скрипт на сайті, який прийматиме дані від CRM, знаходить відповідне замовлення за його номером і змінює статус на сайті відповідно до статусу в CRM.

Як це буде працювати:

• Змінюється статус замовлення в CRM і спрацьовує тригер, який надсилає на сайт JSON з даними цього замовлення. Він включає "source_uuid" (номер замовлення на сайті) та "status_id" (ID статусу в CRM);
• Скрипт на сайті приймає дані, знаходить замовлення за "source_uuid" і оновлює його статус відповідно до переданого "status_id" із CRM.