Разработвай с BasketBooster

Документация за твоя AI асистент (MCP)

Claude Code, Cursor и другите асистенти с MCP поддръжка могат да се свържат директно с нашия сървър за документация. Свързаният асистент може да изброява, чете и търси във всяко ръководство за интеграция, така че заявка от рода на „добави препоръки от BasketBooster на продуктовата ми страница" получава отговор от актуалната документация, а не от паметта на модела.

claude mcp add --transport http basketbooster-docs https://api.basketbooster.eu/mcp

{
  "mcpServers": {
    "basketbooster-docs": { "url": "https://api.basketbooster.eu/mcp" }
  }
}

{
  "mcpServers": {
    "basketbooster-docs": {
      "type": "http",
      "url": "https://api.basketbooster.eu/mcp"
    }
  }
}

Сървърът предоставя три инструмента: list_docs, read_doc и search_docs. Ръководствата покриват първите стъпки, вграждането на модулите, пълния API справочник, плъгина за WooCommerce, ключовете и CORS, както и плановете и плащанията. Не ти трябва акаунт или API ключ, за да се свържеш.

Документация като чист текст (llms.txt)

Нямаш MCP? Всяко ръководство е публикувано и като чист markdown, индексиран на https://api.basketbooster.eu/llms.txt. Всеки файл е обикновен markdown, така че можеш да поставиш адреса в ChatGPT, Claude или редактора си и да работиш направо от него.

Интерактивен API справочник (Swagger)

Разгледай и пробвай публичното API направо в браузъра на https://api.basketbooster.eu/docs. Покрива цялата повърхност за интеграция:

Суровата OpenAPI спецификация е на https://api.basketbooster.eu/openapi.json. Подай я на генератор на код или на AI асистента си.

Проследяване на реализациите и приписване

Модулите <product-recs> отчитат автоматично разглеждания на продукти (detail-page-view), показвания на препоръки (rec-impression) и кликвания по препоръки (rec-click). За тях не е нужен код в сайта ти. Те обаче не виждат бутона за количката и страницата за плащане, така че събитията за добавяне в количката и покупка трябва да идват от твоя магазин. Плъгинът за WooCommerce изпраща и двете вместо теб; при собствен магазин ги свързваш веднъж.

<script>
  ProductRecs.track('add-to-cart', {
    item_id: '123',
    user_id: 'CUSTOMER_ID',  // logged-in customer id, omit for guests
    value: 49.9,             // line value (unit price x quantity)
    currency: 'EUR'
  });
</script>

curl -X POST "https://api.basketbooster.eu/v1/orders" \
  -H "X-API-Key: YOUR_SECRET_KEY" -H "Content-Type: application/json" \
  -d '{
    "order_id": "ORDER_1234",
    "user_id": "cust_9",
    "session_id": "s_...",
    "currency": "EUR",
    "items": [{"item_id": "123", "quantity": 2, "price": 19.9}]
  }'

Пази идентификатора на клиента еднакъв

Таблото Impact приписва добавяне в количката или продажба на препоръките само когато търговското събитие и по-ранно кликване или показване на препоръка носят една и съща самоличност на клиента и един и същ продуктов идентификатор, в рамките на 30 дни. Самоличността е user_id, когато го има, иначе автоматичният сесиен идентификатор на модула. Когато се изпращат и двете, user_id печели.

За влезли в профила си клиенти подавай идентификатора на клиента навсякъде: data-user-id при всяко вграждане на модул, user_id при извикванията за добавяне в количката и покупка, и user_id при POST /v1/orders. Ако модулите работят анонимно, а поръчките ти носят идентификатор на клиент, нищо не съвпада и приписването остава нула.

За анонимни клиенти модулът пази сесийния си идентификатор в localStorage["pr_sid"], а извикванията на ProductRecs.track от браузъра го поемат автоматично. За синхронизация на поръчки от сървъра препиши идентификатора в собствена бисквитка и го подай като session_id:

<script>
  try {
    var sid = localStorage.getItem('pr_sid');
    if (sid) document.cookie = 'pr_sid=' + encodeURIComponent(sid) +
      '; path=/; max-age=15552000; SameSite=Lax';
  } catch (e) {}
</script>

После прочети бисквитката на сървъра си (тук е показано с PHP):

$sid = $_COOKIE['pr_sid'] ?? '';
if (preg_match('/^s_[A-Za-z0-9]+$/', $sid)) {
    $payload['session_id'] = $sid;
}