Skirbo +
Big Cartel

Сохранить точный вариант и не отправить больше заказанного. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

Операция	Направление	Состав и готовность
Заказ магазина	Big Cartel → Skirbo	Обсудим в составе подключения Сохранить аккаунт, внешний заказ и физические варианты позиций.
Каталог вариантов	Big Cartel → Skirbo	Обсудим в составе подключения Сопоставить варианты лимитированного товара с отдельными SKU.
Результат отправления	Skirbo → Big Cartel	Нужна проверка Подтвердить разрешённый способ отражения отправки и проверку принятого результата.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Big Cartel рассматриваем как магазин продавца, часто с ограниченными тиражами и вариантами товара. Для фулфилмента критичны идентификатор аккаунта, опция товара и исходная строка заказа: трек без количества строки не подтверждает полноту отправки.

Как организовать обмен

Для приложений описаны OAuth и проверка/допуск партнёрского приложения. Private Basic для собственного магазина не превращаем в запрос пароля каждого клиента. JSON:API media type и identifying User-Agent описаны в сохранённом контракте.

Предлагаемый порядок работы

Получаем заказ в области account ID и проверяем оплату по согласованному правилу. Shipping status не используется как доказательство оплаты.
Сохраняем id строки, product_id, product_option_id и количество. Вариант ограниченного тиража связываем со складским SKU, не подбираем по одному названию.
Skirbo резервирует конкретные экземпляры на складе клиента и фиксирует фактическое количество в партии. Недостающий вариант не заменяется другим без согласия продавца.
Создаём shipment с items[].order_line_item_id и items[].quantity, реальными данными перевозчика и осознанным notify_customer. Решение об уведомлении не оставляем случайному значению.
После создания сохраняем shipment ID/Location и читаем ресурс для проверки строк и трека. Сумма уже созданных партий и новой партии проверяется против заказа как правило проекта.
Принятый shipment связываем с физической партией и отражаем оставшееся количество к исполнению. Отправка письма не является подтверждением вручения посылки.
При потере ответа ищем существующее отправление до повтора. Отмена, невыясненная оплата или отсутствие нужного option переводят заказ в очередь разбора; повторный webhook не создаёт вторую сборку.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Частичная отправка ограниченного тиража

Задача: Сохранить точный вариант и не отправить больше заказанного.

Когда начинается: Коммерчески допущенный заказ содержит физические позиции, готовые к сборке.

Получаем заказ в области account ID и проверяем оплату по согласованному правилу. Shipping status не используется как доказательство оплаты.
Сохраняем id строки, product_id, product_option_id и количество. Вариант ограниченного тиража связываем со складским SKU, не подбираем по одному названию.
Skirbo резервирует конкретные экземпляры на складе клиента и фиксирует фактическое количество в партии. Недостающий вариант не заменяется другим без согласия продавца.
Создаём shipment с items[].order_line_item_id и items[].quantity, реальными данными перевозчика и осознанным notify_customer. Решение об уведомлении не оставляем случайному значению.
После создания сохраняем shipment ID/Location и читаем ресурс для проверки строк и трека. Сумма уже созданных партий и новой партии проверяется против заказа как правило проекта.
Принятый shipment связываем с физической партией и отражаем оставшееся количество к исполнению. Отправка письма не является подтверждением вручения посылки.
При потере ответа ищем существующее отправление до повтора. Отмена, невыясненная оплата или отсутствие нужного option переводят заказ в очередь разбора; повторный webhook не создаёт вторую сборку.

Результат: Частичные партии и ограниченные варианты остаются прослеживаемыми до исходной строки.

Если возникло исключение

Доступ приложения требует условий и допуска Big Cartel; эта карточка не утверждает, что приложение Skirbo одобрено.

Опции товара и доступный тираж

Задача: Отличить складской вариант от родительского продукта.

Когда начинается: Изменилось количество или статус опции товара.

Карта использует product и option ID с account ID, сохраняя физический SKU и владельца товара.
Владелец резерва определяет доступный тираж; обновление и сверка каталога выполняются только по подтверждённому контракту выбранного приложения.
Товар, скрытый или снятый с продажи, сохраняет историю ранее принятых заказов.

Результат: Тираж и варианты не смешиваются с визуальным оформлением магазина.

Если возникло исключение

Планируемые product drops не автоматизируются через неподдержанный API.

Смена домена магазина и отключение приложения

Задача: Сохранить учёт заказов при изменении доступа.

Когда начинается: Продавец сменил адрес магазина либо отозвал разрешение приложения.

Связь с клиентом сохраняется по account ID, домен обновляется как атрибут.
При отзыве доступа прекращаем новые запросы и выделяем уже принятые заказы для согласованного завершения.
После восстановления разрешения сверяем открытые заказы и отправления, прежде чем возобновить автоматическую обработку.

Результат: Домен не создаёт второй магазин, а потеря токена не теряет физические обязательства.

Если возникло исключение

Повторная авторизация не должна повторно отправлять все старые заказы.

Возврат одной опции лимитированной коллекции

Задача: Вернуть в доступный тираж только фактически принятый и пригодный экземпляр.

Когда начинается: Продавец согласовал возврат позиции ранее отправленного заказа.

Оператор связывает ожидаемый возврат с account ID, исходным заказом, строкой, option и ранее созданной партией. Согласование возврата не изменяет доступный тираж.
Склад принимает посылку, сверяет вариант и количество, осматривает состояние и фиксирует отдельно годные, повреждённые и отсутствующие единицы.
Ответственный продавца подтверждает финансовое решение в своём платёжном контуре; запись shipment и уведомление покупателя не используются как подтверждение refund.
Годные единицы возвращаются в физический запас один раз по ключу возврата. Изменение публикуемого количества Big Cartel выполняется только по отдельно подтверждённому stock-контракту либо согласованной операторской процедуре.
Сверяют исходную строку, итог осмотра, складское количество и результат в магазине. Повторное сообщение по тому же возврату проверяет журнал, а повреждённый экземпляр не становится доступным к продаже.

Результат: Физическая приёмка, финансовое решение и новый доступный тираж подтверждены раздельно.

Если возникло исключение

Автоматический API возвратов и корректировки stock в этой карточке не подтверждён; исторический вопрос по ним остаётся открытым.

Кто управляет данными

Данные	Ответственный источник	Правило обмена
Заказ и строки	Big Cartel Order	Коммерческий состав и оплата принадлежат магазину, склад исполняет разрешённые строки.
SKU и варианты	Big Cartel product/option и карта склада	option ID сохраняется отдельно от product ID.
Остатки и резерв	Согласованный учёт тиража	Резерв и публикуемое количество определяются одним владельцем.
Статусы	Big Cartel shipments и физический факт	payment status, shipping status и вручение не объединяются.
Документы	Учёт/платёжный контур продавца	Shipment не заменяет финансовый документ.
Возвраты	Продавец и склад осмотра	Возврат привязан к option и исходной строке, годный тираж восстанавливается после приёмки.

Что обсудить перед пилотом

Одобрено ли приложение и какие права доступны магазину?
Какая операция изменяет остаток и как отражается физический возврат?
Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Какое значение type принимает обновление shipment в выбранной версии, учитывая расхождение таблицы и примера?

Перед оценкой

Что нужно уточнить

Магазин Big Cartel, приложение OAuth и перечень разрешённых операций.
Соответствие вариантов и SKU, включая ограниченные тиражи.
Правила допуска заказа и обработки повторных уведомлений.
Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.

Границы сценария

Что учесть заранее

Webhook сообщает об изменении, но не подтверждает физическую сборку и не отменяет сверку заказа.
Тарифные ограничения и доступность операций проверяются по действующим условиям магазина, без переноса старых оценок лимитов.
Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
Подписка на webhooks требует OAuth-приложения; доступность выбранного типа события проверяется отдельно от API-операции.

Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Как не продать последнюю единицу лимитированного тиража дважды?

Вопросы о подключении

Как не продать последнюю единицу лимитированного тиража дважды?

Сначала определим владельца резерва и момент уменьшения доступности. Остаток каждого варианта сверяется после исполнения, а повтор события не создаёт новый резерв.

Достаточно ли только уведомления webhook?

Для надёжного исполнения нужна проверка актуального заказа и учёт повторов. Конкретное событие и права чтения подтвердим при проектировании.

Достаточно отправить трек без строк?

Для документированного создания shipment нужны количества и идентификаторы строк заказа. Они связывают конкретную партию с составом заказа и позволяют проверить частичное исполнение.

Смена домена нарушит связь со складом?

В предлагаемой схеме магазин привязан к account ID. Домен является изменяемым атрибутом; после изменения выполняется сверка доступа и открытых заказов.

Можно ли получить события с доступом только к собственному магазину?

Нужно проверить тип авторизации: документация связывает webhooks с OAuth-приложением. Для выбранного события также проверяют план магазина. Возможность чтения API сама по себе не подтверждает доступ к событиям.

Интеграция уже готова?

По запросу: предлагается индивидуальное проектирование и проверка на среде клиента. Принятый коннектор Skirbo, доступность пилота, срок запуска и SLA не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Big Cartel API — дата проверки: 2026-10-30
Big Cartel API v1: application access, shipments and webhooks — дата проверки: 2026-10-30

Посмотрите другие сценарии

Весь каталог →

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.

Skirbo +Big Cartel

Какой обмен обсудим

Для какой задачи подходит сервис

Как организовать обмен

Предлагаемый порядок работы

Практические сценарии

Частичная отправка ограниченного тиража

Если возникло исключение

Опции товара и доступный тираж

Если возникло исключение

Смена домена магазина и отключение приложения

Если возникло исключение

Возврат одной опции лимитированной коллекции

Если возникло исключение

Кто управляет данными

Что обсудить перед пилотом

Что нужно уточнить

Что учесть заранее

Оценим ваш набор операций

Вопросы о подключении

Посмотрите другие сценарии

Tilda

InSales

1С-Битрикс: Управление сайтом

Что хотите связать со Skirbo?

Skirbo +
Big Cartel