Dla programistów

Zweryfikowanezweryfikowano 2026-09-20

W skrócie

MitoOps ma publiczny interfejs w trzech postaciach nad tą samą znormalizowaną warstwą danych. Różnią się tym, kto pyta i co może:

Postać	Kierunek	Co może
REST API (`/api/v1`)	pyta własny program	tylko odczyt: odpowiada wyłącznie na `GET`, żadna operacja niczego nie zmienia
MCP (`/api/mcp`)	pyta aplikacja AI	odczyt tych samych danych, a dodatkowo wąskie zapisy za wrażliwymi zakresami, które człowiek przyznaje wyraźnie: `automations:write` (wyłączony szkic automatyzacji i propozycja zmiany działającej, którą publikuje człowiek), `coupons:write` i `coupons:delete` (kupon rabatowy z podglądem i potwierdzeniem), `affiliate:write` (zarządzanie programem partnerskim: konto partnera, teksty portalu, szablony, kampanie, polityka dokumentów), `affiliate:approve` (decyzja o jednej wskazanej prowizji, wypłaty pozostają w aplikacji), `availabilities:draft` (propozycja zmiany słownika dostępności, którą do e-shopu zapisuje dopiero człowiek, zatwierdzając ją w aplikacji) oraz `claims-settings:draft` (propozycja zmiany ustawień reklamacji, którą zapisuje dopiero człowiek, zatwierdzając ją w aplikacji). Ponadto `claims-routes:draft`, `product-content:draft` oraz `category-content:draft`: propozycja transportu zwrotnego reklamacji oraz tekstów produktów i kategorii, którą zapisuje człowiek, zatwierdzając ją w aplikacji, albo od razu, jeśli klient świadomie włączy dla tego obszaru zapis autonomiczny. Nic innego przez MCP nie powstaje ani się nie zmienia
Webhooki wychodzące	MitoOps wysyła do odbiorcy	podpisana wiadomość o zdarzeniu (zamówienie, płatność, przesyłka, magazyn, faktura, reklamacja) na podany adres

Interfejs udostępnia obecnie 130 narzędzi MCP (102 do odczytu, 28 do zapisu za wrażliwymi zakresami: szkic i rewizja automatyzacji, kupony rabatowe, zarządzanie programem partnerskim oraz propozycje zmian dostępności, ustawień i transportu zwrotnego reklamacji oraz tekstów produktów i kategorii, które zapisuje dopiero człowiek, zatwierdzając je w aplikacji, chyba że klient świadomie włączy dla obszaru zapis autonomiczny), 101 ścieżek REST (wszystkie tylko do odczytu) i 32 zakresów uprawnień, w tym 13 wrażliwych, w 19 obszarach danych. Liczby powstają z katalogu aplikacji podczas budowania tej strony, nikt ich nie wpisuje ręcznie.

Co można odczytać przez REST i MCP: e-shopy, zamówienia, produkty i kategorie, zapasy z historią ruchów, faktury i korekty, przesyłki i statystyki doręczeń, ruch i kanały, zestawienia finansowe i sprzedaż, katalog klientów i analitykę klientów w pseudonimach, dostawców, reklamacje ze statystyką, program partnerski, automatyzacje, słownik dostępności e-shopów, endpointy webhooków oraz taryfę konta z limitami.

Przez MCP nie da się zmienić zamówienia ani jego statusu, stanu zapasów, produktu ani tego, jaką dostępność ma produkt, ceny, wystawić dokumentu, wykonać refundacji, zarządzać endpointami webhooków, włączyć automatyzacji, zbiorczo zatwierdzić prowizji ani wypłacić partnerowi. Każdy zapis wymaga własnego wrażliwego zakresu: wyłączony szkic automatyzacji (włącza go dopiero człowiek w aplikacji), kupon rabatowy (podgląd i potwierdzenie), zarządzanie programem partnerskim, decyzja o jednej wskazanej prowizji i propozycja zmiany słownika dostępności (do e-shopu zapisuje ją dopiero człowiek, gdy zatwierdzi ją w aplikacji). REST w ogóle nie ma wywołań zapisujących. Danych dostępowych do przewoźników, e-shopu ani analityki nie da się odczytać niczym.

REST: tylko odczyt

Adres to /api/v1 w domenie aplikacji. Wywołania, parametry, kształt odpowiedzi, okres i stronicowanie opisuje interfejs REST. Maszynowo czytelny opis jest pod /api/v1/openapi.json za tym samym kluczem; zalogowany człowiek może go otworzyć także z ekranu Ustawienia → API & MCP. Opis powstaje z tego samego źródła co interfejs, więc się z nim nie rozejdzie.

Wszystko inne niż GET otrzymuje 405, zanim serwer spojrzy na klucz. Nie jest to tymczasowe ograniczenie: REST v1 nie ma wywołań zapisujących, a zapisy MCP celowo do niego nie trafiły. Propozycję zmiany dostępności można przez REST tylko odczytać (jej stan), przygotować jej przez REST nie można.

MCP: odczyt i wąskie zapisy

Adres to /api/mcp. MitoOps to standardowy zdalny serwer MCP (Model Context Protocol, otwarty protokół niezależny od dostawcy AI); podłączy się każda aplikacja, która obsługuje zdalne MCP przez HTTP z OAuth lub z kluczem dostępu. Claude.ai to produkcyjnie sprawdzony klient; dokładny sposób postępowania opisuje interfejs MCP.

Narzędzia MCP stoją na tych samych możliwościach co REST: nie jest to drugi interfejs z własnymi zapytaniami. Lista narzędzi zależy od zakresów klucza lub zgody: narzędzie spoza zakresu dla aplikacji nie istnieje. Każde narzędzie niesie adnotacje zgodne z rewizją protokołu 2026-07-28 (readOnlyHint, destructiveHint, idempotentHint), z których aplikacja AI wie, czy chodzi o odczyt, czy o zapis.

OAuth: połączenie w imieniu człowieka

Aplikacja AI, która obsługuje zdalne MCP z OAuth, nie łączy się kluczem. Podaje się jej adres /api/mcp, a ona przekierowuje do logowania w MitoOps (także z drugim czynnikiem), gdzie na ekranie zgody wybiera się, co może odczytywać, których e-shopów to dotyczy i jakie zapisy może wykonywać (szkice automatyzacji, kupony, zarządzanie programem partnerskim, decyzja o prowizji, propozycje zmian dostępności). Hasła aplikacja nigdy nie zobaczy.

O tym, co jest przekazywane, decyduje zalogowany człowiek, i nigdy nie więcej, niż sam może. Kto nie ma prawa do cen zakupu, nie może go przekazać dalej; kto nie może edytować automatyzacji, w ogóle nie zobaczy zakresu automations:write na ekranie zgody. Zgoda OAuth nie zużywa klucza dostępu z limitu taryfy, ale wymaga taryfy z API & MCP: bez niej ekran zgody się nie otworzy i poda powód.

Uprawnienie można w każdej chwili odebrać w Ustawienia → API & MCP, a wszystkie dostępy z niego przestają obowiązywać w tej samej chwili.

Klucz dostępu

Dla serwera, który wywołuje serwer, lub dla własnego programu:

W aplikacji otworzyć Ustawienia → API & MCP i nacisnąć Nowy klucz.
Podać nazwę, po której klucz będzie można później rozpoznać.
Wybrać zakresy, e-shopy i interfejsy (REST, MCP lub oba).
Wybrać ważność i utworzyć klucz.

Klucz wysyła się w nagłówku; w adresie celowo nie jest przyjmowany (adresy trafiają do logów i historii przeglądarki):

Authorization: Bearer <klucz API>

Zakresy uprawnień

Klucz ani zgoda nigdy nie widzą więcej, niż zostało im przyznane. Tabela powstaje z katalogu aplikacji:

Zakres	Dostęp	Wrażliwy	Co udostępnia
`stores:read`	odczyt	nie	listę e-shopów z kodem
`orders:read`	odczyt	nie	zamówienia łącznie z pozycjami; adres tylko kraj i miasto, kwoty tylko z `reports:read`
`products:read`	odczyt	nie	produkty, kategorie i cenę sprzedaży z karty produktu
`invoices:read`	odczyt	nie	faktury z pozycjami, korekty i faktury zaliczkowe
`shipping:read`	odczyt	nie	przesyłki, zdarzenia śledzenia, przewoźników (bez danych dostępowych) i statystyki doręczeń
`analytics:read`	odczyt	nie	ruch, kanały, wyniki w wyszukiwarce i pokrycie zamówień pomiarem
`search-console:read`	odczyt	nie	skuteczność w wyszukiwarce Google z zsynchronizowanego archiwum: dni, zapytania, strony, kraje i urządzenia
`inventory:read`	odczyt	nie	stan zapasów i historię ruchów magazynowych
`reports:read`	odczyt	wrażliwy	obrót z porównaniem i według miesięcy, reklama (wydatki, budżet, ROAS, udział wydatków w obrocie, CPA, MER), kiedy przychodzą zamówienia, źródła obrotu; podsumowanie finansowe okresu (obrót, VAT, koszty, wynik), sprzedaż według produktów, wyniki według zamówień, klientów jako pseudonimy i kwoty w zbiorczej liście zamówień
`purchasing:read`	odczyt	wrażliwy	dostawców, ich oferty i składniki kosztów
`claims:read`	odczyt	nie	reklamacje i zwroty z powiązaniami z zamówieniem, korektą i przesyłką zwrotną, oś czasu i wysłane e-maile zgłoszenia; statystykę i procesy modułu
`automations:read`	odczyt	nie	katalog wyzwalaczy i akcji, listę automatyzacji, ich ustawienia, historię przebiegów i walidację propozycji
`automations:write`	zapis	wrażliwy	utworzenie lub edycję wyłączonego szkicu automatyzacji i propozycję zmiany włączonej automatyzacji (rewizję); włączyć szkic i opublikować rewizję może tylko człowiek w aplikacji, działająca automatyzacja nie zmienia się przez propozycję
`webhooks:read`	odczyt	nie	katalog zdarzeń, endpointy bez tajnego klucza i dziennik doręczeń bez treści
`account:read`	odczyt	nie	taryfę, włączone funkcje i limity z aktualnym wykorzystaniem
`affiliate:read`	odczyt	nie	program partnerski: przegląd, partnerów, kampanie, kody rabatowe, konwersje, wypłaty, statystykę, ustawienia, dokumenty, publiczny portal, szablony e-maili, artykuły pomocy i wnioski o kod; kontakt partnera tylko z `personal-data:read`, danych bankowych i podatkowych nigdy
`affiliate:write`	zapis	wrażliwy	zarządzanie programem partnerskim: decyzję o koncie partnera (zatwierdzić, odrzucić, zawiesić), obsługę wniosku o kod, ustawienia programu poza pieniędzmi, teksty portalu, artykuły pomocy, szablony e-maili, kampanie i politykę dokumentów; decyzja o prowizji ma własny zakres, wypłaty pozostają w aplikacji
`affiliate:approve`	zapis	wrażliwy	decyzję o jednej prowizji programu partnerskiego według id konwersji: zatwierdzić, odrzucić lub anulować (odrzucenie i anulowanie z powodem, partner otrzymuje e-mail); wypłacona nie jest cofana, zbiorcze zatwierdzanie ani wypłaty z zewnątrz nie istnieją
`customers:read`	odczyt	nie	katalog klientów: pseudonim, e-shopy, kraj, język, liczby i daty z całego życia; imię i nazwisko, firma, e-mail i telefon tylko z `personal-data:read`, obrót i LTV tylko z `reports:read`
`coupons:read`	odczyt	nie	kupony rabatowe e-shopu z wysokością rabatu i ważnością, wsparcie platformy, link aktywacyjny i jego gotowość
`coupons:write`	zapis	wrażliwy	założenie kuponu w wybranych e-shopach (istniejący z innymi parametrami nie zostanie nadpisany bez wyraźnej zgody)
`coupons:delete`	zapis	wrażliwy	nieodwracalne usunięcie kuponu w wybranym e-shopie po podglądzie i wyraźnym potwierdzeniu; kupon z aktywną zależnością (AI Mailing, okno rejestracji, zaplanowana kampania, partner) nie zostanie usunięty
`chatbot:read`	odczyt	nie	statystykę chatbota internetowego za okres: wyświetlenia i kliknięcia wiadomości (wskaźnik kliknięć), otwarcia czatu wraz z tym, czym powstały, liczbę rozmów i wiadomości, wyniki, oceny klientów, lejek zapisu na newsletter i deterministyczną ocenę tematów rozmów (udziały, produkty, kandydaci na lukę); tylko sumy
`chatbot-conversations:read`	odczyt	wrażliwy	rozmowy klientów z chatbotem internetowym: listę z pierwszym pytaniem i zapis ze źródłami odpowiedzi bota; klient jest tylko losowym kluczem rozmowy, e-mail, telefon i IBAN w tekście tylko z `personal-data:read`, w przeciwnym razie zastąpione znacznikiem; tylko w ramach retencji e-shopu
`availabilities:draft`	zapis	wrażliwy	propozycję zmiany słownika dostępności e-shopu (założyć, edytować, usunąć) z podglądem; do e-shopu zapisuje ją dopiero człowiek z uprawnieniem, gdy zatwierdzi ją w aplikacji, w przeciwnym razie wygasa po 24 godzinach; nie zmienia przypisania dostępności do produktów ani stanu zapasów
`claims-settings:read`	odczyt	nie	szablony e-maili i protokołów reklamacji, ustawienia modułu, etykiety, transport zwrotny i formularz w e-shopie; bez tokenów dostępu
`claims-settings:draft`	zapis	wrażliwy	propozycję zmiany procesów, statusów, etykiet i tekstów szablonów reklamacji z podglądem; zapisuje ją dopiero człowiek z uprawnieniem, zatwierdzając w aplikacji, w przeciwnym razie wygasa po 72 godzinach; niczego nie usuwa
`claims-routes:draft`	zapis	wrażliwy	propozycja utworzenia, zmiany, włączenia lub wyłączenia trasy zwrotnej, sprawdzana jak na ekranie; zapisuje ją człowiek, zatwierdzając w aplikacji, albo od razu, jeśli klient świadomie włączył dla obszaru zapis autonomiczny; nigdy nie usuwa trasy
`product-content:read`	odczyt	nie	opis, krótki opis i teksty SEO produktu bezpośrednio ze sklepu, z odciskiem i informacją o możliwości zapisu każdego pola
`product-content:draft`	zapis	wrażliwy	propozycja nowych tekstów produktów (do 30 naraz), tylko pola treści, nigdy cena, stan, kod ani EAN; zapisuje ją człowiek, zatwierdzając, albo od razu przy świadomie włączonym zapisie autonomicznym
`category-content:read`	odczyt	nie	górny i dolny opis oraz teksty SEO kategorii, z odciskiem i możliwością zapisu zależną od platformy sklepu
`category-content:draft`	zapis	wrażliwy	propozycja nowych tekstów kategorii (do 30 naraz), tylko pola, które platforma sklepu potrafi zapisać; zapisuje ją człowiek, zatwierdzając, albo od razu przy świadomie włączonym zapisie autonomicznym

Zakresy wrażliwe nie są domyślnie zaznaczone ani na ekranie wydawania klucza, ani na ekranie zgody: człowiek musi zaznaczyć je świadomie. purchase-prices:read i personal-data:read nie mają własnego narzędzia; decydują o polach w odpowiedziach pozostałych. Brakujące pole nie jest zerowe: po prostu go nie ma.

Zakresy to publiczne zobowiązanie: zmieniają się tylko w sposób zgodny wstecz, a poświadczenie wydane wcześniej nie dziedziczy nowego zakresu (zakresy są w nim zapisane z nazwy). Dlatego starszy klucz ani starsza zgoda nie otrzymały danych osobowych, gdy 2.09.2026 powstał dla nich własny zakres, i nie otrzymają też zapisu szkicu: do tego potrzebna jest nowa zgoda lub nowy klucz.

Nowy zakres można dodać do istniejącego klucza także bez wymiany klucza: Ustawienia → API & MCP → Edytuj zakresy. Wartość klucza pozostaje bez zmian, integracja, która go używa, działa dalej i otrzymuje nowy zakres od następnego żądania. Zmianę wprowadza osoba z prawem do zarządzania kluczami; taryfa i zakresy wrażliwe są sprawdzane tak samo jak przy wydaniu.

Dane osobowe

Interfejs wydaje dane operacyjne, osobowe tylko z zakresem personal-data:read:

Zamówienia i reklamacje bez niego zwracają tylko kraj i miasto, a nie imię i nazwisko, e-mail, telefon ani ulicę.
Katalog klientów (customers:read) sam wydaje tylko pseudonim, e-shopy, kraj, język, liczby i daty. Imię i nazwisko, firmę, e-mail, telefon i płeć marketingową dodaje dopiero personal-data:read, obrót i LTV dopiero reports:read; brakujące pole jest usuwane, a nie zerowane.
Analityka klientów (customers/performance) w ogóle nie ma danych osobowych: klient jest pseudonimem (odciskiem e-maila), takim samym jak customerEmailHash na dokumentach i w katalogu.
Kontakt dostawcy i partnera programu wymaga tego samego zakresu.
Rozmowy z chatbotem internetowym (chatbot-conversations:read, wrażliwy) niosą tylko losowy klucz rozmowy, bez imienia, e-maila, IP czy cookie. E-mail, telefon i IBAN, które klient wpisał w tekst, wydaje dopiero personal-data:read; bez niego w ich miejscu jest znacznik.
Dane bankowe i podatkowe partnerów (IBAN, numery identyfikacyjne firmy i podatkowe, dane rozliczeniowe wypłat), notatki wewnętrzne, hasła i tajne klucze drugiego czynnika nigdy nie są wydawane: żaden zakres ich nie otwiera.
Webhooki wysyłają identyfikatory i statusy, a nie treść zamówienia ani dane klienta.

Każde wywołanie jest zapisywane w audycie bez wartości wejściowych, tylko z nazwami pól i odciskiem.

Automatyzacje: bezpieczny zapis szkicu

Asystent AI może automatyzację zaproponować, nie może jej włączyć. Z zakresem automations:write (wrażliwy, nigdy wstępnie zaznaczony, oferowany tylko człowiekowi z prawem do edycji automatyzacji):

automations_create_draft tworzy szkic w stanie wyłączonym: nie dotyka opublikowanej wersji, wyzwalaczy ani przebiegu;
automations_update_draft edytuje tylko szkic, którego nikt jeszcze nie opublikował; szkic rozpoczęty w edytorze aplikacji nie zostanie nadpisany;
szkic pojawia się w Automatyzacjach jak każda rozpoczęta propozycja, a włączyć, opublikować lub uruchomić go może tylko człowiek w aplikacji z prawem do zatwierdzania;
automations_revision_create_draft proponuje zmianę automatyzacji opublikowanej i włączonej jako rewizję; działająca wersja się nie zmienia, dopóki człowiek nie wczyta rewizji w edytorze i jej nie opublikuje (automations_revision_update_draft, automations_revision_discard_draft).

Wartości pól, które w edytorze wybiera się z listy (status zamówienia, metoda dostawy, płatność, status reklamacji…), zwraca automations_options w postaci, w jakiej zapisuje je edytor. Wartość, która w e-shopie nie istnieje, i tekst zastępczy typu DOPLNIT_… to błąd walidacji, a nie sukces.

Tworzenie jest idempotentne przez clientRequestId, edycja wymaga expectedVersion, a oba wymagają catalogVersion z automations_catalog: przestarzały katalog to konflikt, a nie cichy zapis. Propozycja, która sięga po nieznany wyzwalacz, e-shop spoza zakresu lub obcy endpoint webhooka, nie zostanie zapisana. Szczegóły w interfejsie MCP.

Dostępności: propozycja zmiany zatwierdzana przez człowieka

Dostępności to pozycje słownika konkretnego e-shopu, które e-shop pokazuje przy produkcie, na przykład Na stanie, Na zamówienie lub Przedsprzedaż: nazwa, opis, zaopatrzenie i dostawa w godzinach, znaczenie dla Google Shopping i kolor. Nie jest to stan zapasów.

availabilities_list i GET /availabilities?market= (zakres products:read) zwracają słownik jednego e-shopu; market jest obowiązkowy. Pole manageable mówi, czy słownik tego e-shopu można zmieniać w MitoOps, a reason, dlaczego nie: PLATFORMA (platforma tego nie potrafi), BEZ_ROZSIRENIA (e-shopowi WooCommerce brakuje wtyczki MitoOps) lub PROSTREDIE (zapis do e-shopów jest w środowisku wyłączony).
availabilities_change_draft (tylko MCP, wrażliwy zakres availabilities:draft) do e-shopu niczego nie zapisuje. Sprawdza zmianę, zapisuje ją jako propozycję ważną 24 godziny i zwraca podgląd (pole przed i po, ostrzeżenia, blokady), draftId i approvalUrl.
Do e-shopu propozycję zapisuje dopiero człowiek w aplikacji przyciskiem Zatwierdź i zapisz w Magazyn → Dostępności → Zarządzanie albo ją odrzuca. Decydują przy tym jego uprawnienia w chwili kliknięcia, a nie zakres klucza czy zgody. Model ani klucz dostępu bez człowieka niczego do e-shopu nie zapiszą.
availabilities_draft_get i GET /availabilities/drafts/:draftId (zakres products:read) zwracają stan propozycji: pending, writing, executed, partial, failed, rejected lub expired.

Zakres availabilities:draft jest oferowany tylko człowiekowi, który mógłby zmianę także zatwierdzić (prawo do zarządzania synchronizacją magazynu i edycji produktów). Istniejący klucz ani zgoda go nie dziedziczą. REST v1 pozostaje tylko do odczytu. Parametry propozycji opisuje interfejs MCP, a ekran zatwierdzania instrukcja Dostępności.

Reklamacje: ustawienia do odczytu i propozycja zmiany

claims_settings (zakres claims:read) zwraca procesy z ID i nazwami typów, kroków i statusów oraz etykiety; z zakresem claims-settings:read także ustawienia modułu.
claims_templates i claims_configuration (zakres claims-settings:read) zwracają szablony e-maili i protokołów (temat, tekst, kiedy i czy są wysyłane automatycznie) oraz pozostałe ustawienia: etykiety, pola, transport zwrotny i formularz w e-shopie, bez tokenu integracji.
claims_get niesie także oś czasu zgłoszenia, wysłane e-maile i etykiety; tekst wiadomości tylko z personal-data:read.
claims_config_change_draft (tylko MCP, wrażliwy zakres claims-settings:draft) ustawień nie zmienia. Zapisuje propozycję zmiany procesów, statusów, etykiet i tekstów szablonów na 72 godziny z podglądem i approvalUrl; zapisuje ją dopiero człowiek z prawem do zarządzania ustawieniami przyciskiem Zatwierdź i zapisz w Reklamacje → Ustawienia, w całości albo wcale. Stan zwraca claims_config_draft_get.

Parametry opisuje interfejs MCP.

Transport zwrotny, teksty produktów i zapis autonomiczny

claims_routes (zakres claims-settings:read lub dowolny zakres propozycji reklamacji) zwraca trasy transportu zwrotnego, adresy odbiorcy, profile przewoźników z ID, znacznikiem zwrotu i zasięgiem oraz klucze typów zgłoszeń. claims_routes_change_draft (tylko MCP, wrażliwy zakres claims-routes:draft) proponuje utworzenie, zmianę, włączenie lub wyłączenie trasy. Serwer sprawdza ją tak samo jak ekran: profil z włączonym zwrotem, zasięg przewoźnika, istniejący adres i typy, nieujemna cena i brak konfliktu z włączoną trasą. Usuwania trasy przez MCP nie ma.
products_content_get i GET /products/:code/content?market= (zakres product-content:read) zwracają opis, krótki opis i teksty SEO produktu bezpośrednio ze sklepu, każde pole z odciskiem (hash) i informacją, czy platforma potrafi je zapisać. categories_content_get i GET /categories/:guid/content?market= (zakres category-content:read) zwracają to samo dla kategorii.
products_content_change_draft i categories_content_change_draft (tylko MCP, wrażliwe zakresy product-content:draft i category-content:draft) proponują nowe teksty, najwyżej 30 pozycji naraz. Przyjmują tylko pola treści; ceny, stanu, dostępności, kodu, EAN ani nazwy w ten sposób nie zmienisz. HTML jest sprawdzany: żadnego skryptu poza jednym blokiem JSON-LD FAQPage, żadnych on…, javascript: ani iframe. Przy zatwierdzeniu tekst jest porównywany ze stanem sklepu, a jeśli ktoś go w międzyczasie zmienił, nic nie zostanie zapisane (CHANGED_SINCE_DRAFT). Gdy sklep zmieni tekst podczas zapisu, wynik to powie (MODIFIED_BY_PLATFORM). Propozycje zatwierdza się w Magazyn → Zmiany produktów. W WooCommerce projekt ze skryptem (także JSON-LD) lub z ukośnikiem wstecznym zostanie zablokowany (PLATFORM_STRIPS_SCRIPT, PLATFORM_STRIPS_BACKSLASH): WordPress usuwa je przy zapisie, a resztę klienci widzieliby jako tekst.
products_content_policy i GET /product-content/policy?market= (zakres product-content:read) mówią bez odpytywania sklepu, co Twój klucz może robić z tekstami w danym sklepie: czy może czytać (readEnabled) i proponować (draftEnabled, propozycje tylko przez MCP), które pola platforma zapisze (supportedFields; pola SEO na WooCommerce tylko z wtyczką SEO), tryb zatwierdzania (approvalMode: human, autonomous lub disabled) i czy propozycja zapisze się sama (autonomousWriteEnabled), limity propozycji i algorytm odcisków (sha256). Wstrzymany sklep, nieobsługiwana platforma lub klucz sklepu tylko do odczytu to status i reason w odpowiedzi, a nie błąd. Pole category zawiera to samo dla kategorii. Pole structuredData mówi, czy platforma zachowuje dane strukturalne w opisie produktu: w WooCommerce nie (NOT_SUPPORTED, PLATFORM_STRIPS_SCRIPT; dane strukturalne obsługuje tam motyw sklepu, THEME_MANAGED), w Shoptet tak (jeden blok FAQPage).
Zapis autonomiczny. Domyślnie każdą propozycję (ustawienia i trasy reklamacji, teksty produktów i kategorii) zapisuje dopiero człowiek, zatwierdzając ją. Administrator może go włączyć dla poszczególnego obszaru w Ustawienia → API & MCP → Zapis przez AI. Propozycja zapisuje się wtedy od razu, tą samą drogą co zatwierdzenie, w imieniu osoby, która udzieliła AI dostępu, i tylko jeśli ta osoba właśnie teraz ma prawo zatwierdzić zmianę. W przeciwnym razie propozycja czeka, a odpowiedź mówi dlaczego. Każda zmiana trybu jest zapisywana.

Istniejący klucz ani zgoda nie dziedziczą nowych zakresów; potrzebna jest nowa zgoda.

Webhooki wychodzące

REST i MCP to odczyt na żądanie. Gdy system ma się dowiedzieć o zdarzeniu od razu (nowe zamówienie, płatność, zmiana statusu, przesyłka, doręczenie, ruch zapasu, faktura, reklamacja), subskrybuje je przez webhooki wychodzące: MitoOps wysyła na podany adres krótką kopertę z identyfikatorami, podpisaną HMAC-SHA256, z ponowieniami przy niepowodzeniu i dziennikiem prób. Szczegóły system odczytuje następnie przez REST.

Subskrypcje zakłada człowiek w aplikacji na tym samym ekranie co klucze; przez REST i MCP endpointy są tylko odczytywane (webhooks:read, bez tajnego klucza). Endpoint można użyć także jako kroku automatyzacji. Szczegóły w webhookach wychodzących.

Limity konta

API & MCP i webhooki są częścią każdej płatnej taryfy od Start wzwyż. Taryfy różnią się liczbą aktywnych kluczy i endpointów, a nie tym, co można odczytać:

Taryfa	API & MCP	Aktywne klucze dostępu	Endpointy webhooków
Wersja próbna	nie	0	0
Początkujący	nie	0	0
Start	tak	1	5
Wzrost	tak	2	20
Pro	tak	5	50
Na miarę	tak	według umowy	według umowy

Limity egzekwuje serwer: próba utworzenia kolejnego klucza lub endpointu ponad limit kończy się odmową z wyjaśnieniem. Wymiana klucza ani rotacja tajnego klucza endpointu nie zużywa miejsca. Obniżenie taryfy nie usuwa istniejących kluczy ani endpointów: przestaje być możliwe utworzenie nowego, dopóki liczba nie spadnie poniżej nowego pułapu. Połączenie przez OAuth nie zużywa klucza.

Aktualne wartości dla konta łącznie z wykorzystaniem (aktywne automatyzacje, przebiegi w miesiącu, e-maile, kredyty) zwraca account_entitlements / GET /account/entitlements z zakresem account:read. Niesie tylko taryfę, funkcje i limity, bez danych rozliczeniowych. Aktualny cennik jest na mitoops.com/cennik.

Limity wywołań

Limit	Na czym jest mierzony	Ile
przed uwierzytelnieniem	na adres, z którego następuje wywołanie	300 wywołań / 60 s
po uwierzytelnieniu	na konkretny klucz	600 wywołań / 60 s

Pierwszy chroni przed zgadywaniem kluczy, drugi należy do właściciela klucza i nie jest z nikim dzielony. Przekroczenie to 429 z nagłówkami RateLimit-*. Nie jest to wielkość taryfowa: za liczbę wywołań nie są naliczane opłaty.

Błędy

Odpowiedź z błędem ma zawsze ten sam kształt i zawiera kod:

{ "error": { "code": "store_required", "message": "…", "requestId": "…" } }

Stan	Kod	Kiedy
`400`	`invalid_request`	parametr nie odpowiada opisowi (zła data, odwrócony okres, nieprawidłowy kursor)
`400`	`store_required`	wywołanie dotyczące danych e-shopu bez `market`
`401`	`unauthorized`	brakujący, nieznany, anulowany lub nieprawidłowy klucz
`403`	`forbidden`	klucz nie ma potrzebnego zakresu
`403`	`store_forbidden`	e-shop spoza zakresu klucza
`404`	`not_found`	rekord nie istnieje (także wtedy, gdy należy do innego e-shopu)
`405`	brak	wszystko inne niż `GET` (REST)
`409`	`conflict`	zapis szkicu natrafił na inną wersję, użyty `clientRequestId` lub zmieniony katalog (MCP)
`429`	`rate_limited`	przekroczony techniczny limit wywołań

Powód odmowy przy 401 nie jest rozróżniany: różnica pomogłaby temu, kto zgaduje klucze. requestId należy podać przy zgłaszaniu problemu pomocy technicznej. Przez MCP błąd, który asystent potrafi naprawić, przychodzi jako wynik narzędzia z flagą isError; błąd protokołu jako błąd JSON-RPC.

Przykłady

# Zamówienia za okres, według stron
curl -H "Authorization: Bearer <klucz API>" \
  "https://<adres aplikacji>/api/v1/orders?market=sk&from=2026-08-01&to=2026-08-31&limit=50"

# Statystyki doręczeń za sierpień
curl -H "Authorization: Bearer <klucz API>" \
  "https://<adres aplikacji>/api/v1/shipping/stats?market=sk&from=2026-08-01&to=2026-08-31"

# Statystyka reklamacji za sierpień
curl -H "Authorization: Bearer <klucz API>" \
  "https://<adres aplikacji>/api/v1/claims/statistics?market=sk&from=2026-08-01&to=2026-08-31"

# Taryfa i limity konta z wykorzystaniem
curl -H "Authorization: Bearer <klucz API>" \
  "https://<adres aplikacji>/api/v1/account/entitlements"

Pytania, na które po podłączeniu odpowie Claude.ai na podstawie danych MitoOps: „Jaka była mediana czasu doręczenia DHL i GLS w sierpniu?”, „Ile zamówień przyszło z ChatGPT?”, „Jaka jest marża produktu X za ostatni miesiąc?” (z purchase-prices:read), „Ile reklamacji jest po terminie?”, „Zaproponuj automatyzację, która przy nieopłaconym zamówieniu po trzech dniach wyśle przypomnienie” (z automations:write powstanie wyłączony szkic), „Zmień w e-shopie SK nazwę dostępności Na zamówienie na Do 5 dni” (z availabilities:draft powstanie propozycja, którą zapisuje się, zatwierdzając ją w aplikacji).

Bezpieczeństwo

Izolacja przestrzeni klientów. Klient wynika wyłącznie z poświadczenia; każdy klient ma własną bazę danych.
Zakres e-shopów to część wspólna listy z poświadczenia i e-shopów podłączonych w danej chwili. Przy wywołaniach dotyczących danych jednego e-shopu market jest obowiązkowy: brakujący e-shop to 400, e-shop spoza zakresu 403.
Uprawnienia człowieka. Ekran zgody oferuje tylko zakresy, które ma sam zalogowany człowiek; decyduje własny zestaw uprawnień konta.
Granice zapisów egzekwuje usługa, a nie adnotacja: szkic automatyzacji powstaje zawsze wyłączony, opublikowana automatyzacja nie zmienia się przez MCP, a propozycja zmiany dostępności niczego nie zapisuje do e-shopu, dopóki człowiek nie zatwierdzi jej w aplikacji.
Ważność i odwołanie. Token dostępu OAuth jest ważny godzinę, token odświeżania 30 dni; odwołana zgoda zatrzymuje każdy token, który z niej powstał. Klucze można natychmiast anulować lub wymienić.
Audyt. Każde wywołanie jest zapisywane z nazwą możliwości, interfejsem i odciskiem danych wejściowych, bez wartości.
Na czym nie można polegać: niepubliczne adresy aplikacji (interfejs to /api/v1 i /api/mcp, nic więcej), bezpośredni dostęp do bazy danych (nie istnieje) i dane dostępowe (interfejs ich nie wydaje).