Fejlesztőknek

Ellenőrizveellenőrizve 2026-09-20

Röviden

A MitoOps nyilvános interfésze három formában érhető el, ugyanazon normalizált adatréteg fölött. Abban különböznek, hogy ki kérdez, és mit tehet:

Forma	Irány	Mit tehet
REST API (`/api/v1`)	az Ön programja kérdez	csak olvasás: kizárólag `GET` kérésekre válaszol, egyetlen művelet sem módosít semmit
MCP (`/api/mcp`)	egy AI alkalmazás kérdez	ugyanazon adatok olvasása, és ezen felül szűk írási műveletek érzékeny hatókörök mögött, amelyeket egy ember kifejezetten megad: `automations:write` (kikapcsolt automatizálási piszkozat és egy futó automatizálás módosítási javaslata, amelyet ember tesz közzé), `coupons:write` és `coupons:delete` (kedvezménykupon előnézettel és megerősítéssel), `affiliate:write` (a partnerprogram kezelése: partnerfiók, portálszövegek, sablonok, kampányok, dokumentumszabályzat), `affiliate:approve` (döntés egyetlen megnevezett jutalékról, a kifizetések az alkalmazásban maradnak), `availabilities:draft` (az elérhetőségi lista módosítási javaslata, amelyet csak egy ember ír be a webáruházba, amikor jóváhagyja az alkalmazásban) és `claims-settings:draft` (a reklamációs beállítások módosítási javaslata, amelyet csak egy ember ír be az alkalmazásban történő jóváhagyással). Továbbá `claims-routes:draft`, `product-content:draft` és `category-content:draft`: javaslat a reklamációk visszaszállítására, valamint a termék- és kategóriaszövegekre, amelyet egy ember ír be jóváhagyással az alkalmazásban, vagy azonnal, ha az ügyfél a területre tudatosan bekapcsolja az autonóm írást. MCP-n keresztül semmi más nem jön létre és nem módosul
Kimenő webhookok	a MitoOps küld Önnek	aláírt üzenet egy eseményről (rendelés, fizetés, küldemény, készlet, számla, reklamáció) az Ön címére

A felület jelenleg 130 MCP-eszközt kínál (102 olvasásra, 28 írásra érzékeny hatókörök mögött: automatizálás vázlata és revíziója, kedvezménykuponok, a partnerprogram kezelése, valamint az elérhetőségek, a reklamációs beállítások és visszaszállítás, valamint a termék- és kategóriaszövegek módosítási javaslatai, amelyeket csak egy ember ír be jóváhagyással az alkalmazásban, hacsak az ügyfél a területre tudatosan be nem kapcsolja az önálló írást), 101 REST-végpontot (mind csak olvasható) és 32 jogosultsági hatókört, ebből 13 érzékeny, 19 adatterületen. A számok az oldal összeállításakor az alkalmazás katalógusából keletkeznek, senki sem írja be őket kézzel.

Amit REST és MCP útján olvashat: webáruházak, rendelések, termékek és kategóriák, készletek a mozgások előzményeivel, számlák és jóváíró számlák, küldemények és kézbesítési statisztikák, látogatottság és csatornák, pénzügyi kimutatások és értékesítések, az ügyféladatbázis és az ügyfélanalitika álnevekkel, beszállítók, reklamációk statisztikával, a partnerprogram, automatizálások, a webáruházak elérhetőségi listái, webhook végpontok és a fiók tarifája a limitekkel.

MCP-n keresztül nem lehet módosítani a rendelést vagy annak állapotát, a készletszintet, a terméket vagy azt, hogy a termékhez milyen elérhetőség tartozik, az árat, nem lehet bizonylatot kiállítani, visszatérítést végezni, webhook végpontokat kezelni, automatizálást bekapcsolni, jutalékokat tömegesen jóváhagyni, és partnernek sem lehet kifizetést teljesíteni. Minden írási művelet saját érzékeny hatókör mögött áll: kikapcsolt automatizálási piszkozat (csak egy ember kapcsolja be az alkalmazásban), kedvezménykupon (előnézet és megerősítés), a partnerprogram kezelése, döntés egyetlen megnevezett jutalékról és az elérhetőségi lista módosítási javaslata (a webáruházba csak egy ember írja be, amikor jóváhagyja az alkalmazásban). A REST-nek egyáltalán nincsenek írási hívásai. A szállítók, a webáruház vagy az analitika hozzáférési adatai semmilyen módon nem olvashatók ki.

REST: csak olvasás

A cím az alkalmazás Ön által használt domainjén található /api/v1. A hívások, a paraméterek, a válasz formája, az időszak és a lapozás a REST interfész oldalon található. A gépileg olvasható leírás a /api/v1/openapi.json címen érhető el ugyanazzal a kulccsal; a bejelentkezett felhasználó a Beállítások → API & MCP képernyőről is megnyithatja. A leírás ugyanabból a forrásból készül, mint az interfész, így nem térhet el tőle.

Minden GET-től eltérő kérés 405 választ kap, még mielőtt a szerver megnézné a kulcsot. Ez nem ideiglenes korlátozás: a REST v1-nek nincsenek írási hívásai, és az MCP írási műveletei szándékosan nem kerültek bele. Az elérhetőségek módosítási javaslatát REST-en keresztül csak olvasni lehet (az állapotát), elkészíteni nem.

MCP: olvasás és szűk írási műveletek

A cím: /api/mcp. A MitoOps szabványos távoli MCP szerver (Model Context Protocol, nyílt, az AI-szolgáltatótól független protokoll); bármely alkalmazás csatlakozhat, amely támogatja a távoli MCP-t HTTP-n keresztül OAuth-tal vagy hozzáférési kulccsal. A Claude.ai éles környezetben ellenőrzött kliens; a pontos lépések az MCP interfész oldalon találhatók.

Az MCP eszközei ugyanazokra a képességekre épülnek, mint a REST: nem egy második interfész saját lekérdezésekkel. Az eszközök listáját a kulcs vagy a hozzájárulás hatókörei határozzák meg: a hatókörön kívüli eszköz az alkalmazás számára nem létezik. Minden eszköz a 2026-07-28-as protokollrevízió szerinti annotációkat hordozza (readOnlyHint, destructiveHint, idempotentHint), amelyekből az AI alkalmazás tudja, hogy olvasásról vagy írásról van-e szó.

OAuth: csatlakozás egy ember nevében

Az az AI alkalmazás, amely támogatja a távoli MCP-t OAuth-tal, nem kulccsal csatlakozik. Ön megadja neki a /api/mcp címet, az alkalmazás átirányítja Önt a MitoOps bejelentkezésre (a második hitelesítési tényezővel együtt), és a hozzájárulási képernyőn kiválasztja, mit olvashat, mely webáruházakra vonatkozik, és milyen írási műveleteket végezhet (automatizálási piszkozatok, kuponok, a partnerprogram kezelése, jutalékdöntés, elérhetőség-módosítási javaslatok). A jelszavát az alkalmazás soha nem látja.

Arról, hogy mi kerül átadásra, a bejelentkezett ember dönt, és soha nem adhat át többet, mint amennyire ő maga jogosult. Aki nem jogosult a beszerzési árakra, az ezt a jogot nem is tudja továbbadni; aki nem szerkesztheti az automatizálásokat, az automations:write hatókört a hozzájárulási képernyőn egyáltalán nem látja. Az OAuth hozzájárulás nem használ fel hozzáférési kulcsot a tarifa limitjéből, de API & MCP funkciót tartalmazó tarifát igényel: enélkül a hozzájárulási képernyő nem nyílik meg, és megmondja, miért.

Az engedély bármikor visszavonható a Beállítások → API & MCP menüpontban, és az összes belőle származó hozzáférés ugyanabban a pillanatban megszűnik.

Hozzáférési kulcs

Szerverek közötti hívásokhoz vagy saját programhoz:

Az alkalmazásban nyissa meg a Beállítások → API & MCP menüpontot, és kattintson az Új kulcs gombra.
Adjon meg egy nevet, amely alapján később felismeri a kulcsot.
Válassza ki a hatóköröket, a webáruházakat és az interfészeket (REST, MCP vagy mindkettő).
Válassza ki az érvényességet, és hozza létre a kulcsot.

A kulcsot fejlécben kell küldeni, a címben szándékosan nem fogadjuk el (a címek bekerülnek a naplókba és a böngésző előzményeibe):

Authorization: Bearer <az Ön kulcsa>

Jogosultsági hatókörök

A kulcs vagy a hozzájárulás soha nem lát többet, mint amit megkapott. A táblázat az alkalmazás katalógusából készül:

Hatókör	Hozzáférés	Érzékeny	Mihez ad hozzáférést
`stores:read`	olvasás	nem	a webáruházak listája a kódjukkal
`orders:read`	olvasás	nem	rendelések a tételekkel együtt; a címből csak az ország és a város, összegek csak `reports:read` mellett
`products:read`	olvasás	nem	termékek, kategóriák és az eladási ár a termékkártyáról
`invoices:read`	olvasás	nem	számlák tételekkel, jóváíró számlák és előlegszámlák
`shipping:read`	olvasás	nem	küldemények, nyomkövetési események, szállítók (hozzáférési adatok nélkül) és kézbesítési statisztikák
`analytics:read`	olvasás	nem	látogatottság, csatornák, keresési eredmények és a rendelések mérési lefedettsége
`search-console:read`	olvasás	nem	Google-keresési teljesítmény a szinkronizált archívumból: napok, lekérdezések, oldalak, országok és eszközök
`inventory:read`	olvasás	nem	készletszint és a készletmozgások előzményei
`reports:read`	olvasás	érzékeny	árbevétel összehasonlítással és havonta, hirdetés (költés, keret, ROAS, reklámköltés aránya, CPA, MER), mikor érkeznek a rendelések, árbevétel forrásai; az időszak pénzügyi összesítője (forgalom, áfa, költségek, eredmény), értékesítés termékenként, teljesítmény rendelésenként, ügyfelek álnéven és összegek a rendelések tömeges listájában
`purchasing:read`	olvasás	érzékeny	beszállítók, ajánlataik és költségösszetevők
`claims:read`	olvasás	nem	reklamációk és visszaküldések a rendeléshez, a jóváíró számlához és a visszaküldeményhez kapcsolódó hivatkozásokkal, az ügy idővonala és az elküldött e-mailek; a modul statisztikája és folyamatai
`automations:read`	olvasás	nem	az eseményindítók és műveletek katalógusa, az automatizálások listája, beállításaik, a futások előzményei és a javaslat validálása
`automations:write`	írás	érzékeny	kikapcsolt automatizálási piszkozat létrehozása vagy szerkesztése és egy bekapcsolt automatizálás módosítási javaslata (revízió); a piszkozatot bekapcsolni és a revíziót közzétenni csak egy ember tudja az alkalmazásban, a futó automatizálás a javaslattól nem változik
`webhooks:read`	olvasás	nem	az események katalógusa, végpontok titkos kulcs nélkül és a kézbesítési napló üzenettörzs nélkül
`account:read`	olvasás	nem	a tarifa, a bekapcsolt funkciók és a limitek az aktuális kihasználtsággal
`affiliate:read`	olvasás	nem	partnerprogram: áttekintés, partnerek, kampányok, kedvezménykódok, konverziók, kifizetések, statisztika, beállítások, dokumentumok, nyilvános portál, e-mail-sablonok, súgócikkek és kódigénylések; a partner elérhetősége csak `personal-data:read` mellett, banki és adóadatok soha
`affiliate:write`	írás	érzékeny	a partnerprogram kezelése: döntés a partnerfiókról (jóváhagyás, elutasítás, felfüggesztés), kódigénylés elintézése, a program pénzügyeken kívüli beállításai, portálszövegek, súgócikkek, e-mail-sablonok, kampányok és dokumentumszabályzat; a jutalékról szóló döntésnek saját hatóköre van, a kifizetések az alkalmazásban maradnak
`affiliate:approve`	írás	érzékeny	döntés a partnerprogram egyetlen jutalékáról a konverzió azonosítója alapján: jóváhagyás, elutasítás vagy törlés (elutasítás és törlés indoklással, a partner e-mailt kap); a kifizetett jutalék nem vonható vissza, tömeges jóváhagyás és kifizetés kívülről nem létezik
`customers:read`	olvasás	nem	ügyféladatbázis: álnév, webáruházak, ország, nyelv, a teljes ügyfélkapcsolatra vonatkozó darabszámok és dátumok; név, cég, e-mail és telefonszám csak `personal-data:read` mellett, forgalom és LTV csak `reports:read` mellett
`coupons:read`	olvasás	nem	a webáruház kedvezménykuponjai a kedvezmény mértékével és érvényességével, a platform támogatása, az aktiváló link és annak készenléte
`coupons:write`	írás	érzékeny	kupon létrehozása a kiválasztott webáruházakban (a meglévő, eltérő paraméterű kupon kifejezett hozzájárulás nélkül nem íródik felül)
`coupons:delete`	írás	érzékeny	kupon visszavonhatatlan törlése a kiválasztott webáruházban előnézet és kifejezett megerősítés után; az élő függőséggel rendelkező kupon (AI Mailing, regisztrációs ablak, ütemezett kampány, partner) nem törölhető
`chatbot:read`	olvasás	nem	a webes chatbot statisztikája egy időszakra: az üzenetbuborék megjelenései és kattintásai (átkattintási arány), a chat megnyitásai azzal együtt, hogy mi indította őket, a beszélgetések és üzenetek száma, eredmények, ügyfélértékelések, a hírlevél-feliratkozási tölcsér és a beszélgetések témáinak determinisztikus kiértékelése (arányok, termékek, tudáshiány-jelöltek); csak összesítések
`chatbot-conversations:read`	olvasás	érzékeny	az ügyfelek beszélgetései a webes chatbottal: lista az első kérdéssel és átirat a bot válaszainak forrásaival; az ügyfél csak a beszélgetés véletlenszerű kulcsa, a szövegben szereplő e-mail, telefonszám és IBAN csak `personal-data:read` mellett, egyébként helyettesítő jelölés áll a helyükön; csak a webáruház adatmegőrzési idején belül
`availabilities:draft`	írás	érzékeny	a webáruház elérhetőségi listájának módosítási javaslata (létrehozás, szerkesztés, törlés) előnézettel; a webáruházba csak akkor kerül be, ha egy jogosult ember jóváhagyja az alkalmazásban, egyébként 24 óra után lejár; nem módosítja sem az elérhetőségek termékekhez rendelését, sem a készletszintet
`claims-settings:read`	olvasás	nem	a reklamációk e-mail- és jegyzőkönyvsablonjai, a modul beállításai, címkék, visszaszállítás és a webáruházi űrlap; hozzáférési tokenek nélkül
`claims-settings:draft`	írás	érzékeny	a reklamációs folyamatok, állapotok, címkék és sablonszövegek módosítási javaslata előnézettel; csak akkor íródik be, ha egy jogosult ember jóváhagyja az alkalmazásban, egyébként 72 óra után lejár; semmit nem töröl
`claims-routes:draft`	írás	érzékeny	javaslat visszaszállítási útvonal létrehozására, módosítására, be- vagy kikapcsolására, a képernyővel azonos ellenőrzéssel; jóváhagyással íródik be az alkalmazásban, vagy azonnal, ha az ügyfél a területre tudatosan bekapcsolta az önálló írást; útvonalat nem töröl
`product-content:read`	olvasás	nem	a termék leírása, rövid leírása és SEO-szövegei közvetlenül a webshopból, minden mező lenyomatával és írhatóságával
`product-content:draft`	írás	érzékeny	új termékszövegek javaslata (egyszerre legfeljebb 30), csak tartalmi mezők, soha nem ár, készlet, kód vagy EAN; jóváhagyással íródik be, vagy azonnal tudatosan bekapcsolt önálló írásnál
`category-content:read`	olvasás	nem	a kategória felső és alsó leírása és SEO-szövegei, lenyomattal és a webshop platformjától függő írhatósággal
`category-content:draft`	írás	érzékeny	új kategóriaszövegek javaslata (egyszerre legfeljebb 30), csak a webshop platformja által írható mezők; jóváhagyással íródik be, vagy azonnal tudatosan bekapcsolt önálló írásnál

Az érzékeny hatókörök nincsenek alapértelmezetten kijelölve sem a kulcs kiadásának képernyőjén, sem a hozzájárulási képernyőn: az embernek tudatosan kell bejelölnie őket. A purchase-prices:read és a personal-data:read hatókörnek nincs saját eszköze; a többi válasz mezőiről döntenek. A hiányzó mező nem nulla, hanem hiányzik.

A hatókörök nyilvános kötelezettségvállalást jelentenek: csak visszafelé kompatibilis módon változnak, és a korábban kiadott hitelesítő adat az új hatókört nem örökli (a hatókörök név szerint vannak benne rögzítve). Ezért a régebbi kulcs vagy régebbi hozzájárulás nem kapott személyes adatokat, amikor 2026. szeptember 2-án ezeknek saját hatókörük lett, és a piszkozatírást sem kapja meg: ahhoz új hozzájárulás vagy új kulcs kell.

Meglévő kulcshoz új hatókör a kulcs cseréje nélkül is hozzáadható: Beállítások → API & MCP → Hatókörök szerkesztése. A kulcs értéke változatlan marad, az azt használó integráció tovább fut, és a következő kéréstől megkapja az új hatókört. A módosítást kulcskezelési joggal rendelkező személy végzi; a tarifát és az érzékeny hatóköröket ugyanúgy ellenőrizzük, mint kiadáskor.

Személyes adatok

Az interfész üzemi adatokat ad ki, személyes adatokat csak a personal-data:read hatókörrel:

A rendelések és reklamációk nélküle csak az országot és a várost adják vissza, a nevet, az e-mail-címet, a telefonszámot és az utcát nem.
Az ügyféladatbázis (customers:read) önmagában csak az álnevet, a webáruházakat, az országot, a nyelvet, a darabszámokat és a dátumokat adja ki. A nevet, a céget, az e-mail-címet, a telefonszámot és a marketing célú nemet csak a personal-data:read adja hozzá, a forgalmat és az LTV-t csak a reports:read. A hiányzó mező eltávolításra kerül, nem nullázódik.
Az ügyfélanalitika (customers/performance) egyáltalán nem tartalmaz személyes adatot: az ügyfél egy álnév (az e-mail-cím ujjlenyomata), ugyanaz, mint a bizonylatokon és az ügyféladatbázisban szereplő customerEmailHash.
A beszállító és a program partnerének elérhetősége ugyanazon hatókör mögött áll.
A webes chatbottal folytatott beszélgetések (chatbot-conversations:read, érzékeny) csak a beszélgetés véletlenszerű kulcsát hordozzák, név, e-mail-cím, IP-cím vagy cookie nélkül. Az ügyfél által a szövegbe írt e-mail-címet, telefonszámot és IBAN-t csak a personal-data:read adja ki; nélküle a helyükön helyettesítő jelölés áll.
A partnerek banki és adóadatai (IBAN, cégazonosító, adószám, a kifizetések számlázási adatai), a belső megjegyzések, a jelszavak és a második tényező titkai soha nem kerülnek kiadásra: egyetlen hatókör sem nyitja meg őket.
A webhookok azonosítókat és állapotokat küldenek, nem a rendelés tartalmát vagy az ügyfél adatait.

Minden hívás bekerül az auditnaplóba a bemeneti értékek nélkül, csak a mezők neveivel és egy ujjlenyomattal.

Automatizálások: biztonságos piszkozatírás

Az AI asszisztens javasolhat automatizálást, de nem kapcsolhatja be. Az automations:write hatókörrel (érzékeny, soha nincs előre kijelölve, és a rendszer csak annak az embernek kínálja fel, aki jogosult automatizálásokat szerkeszteni):

az automations_create_draft kikapcsolt állapotú piszkozatot hoz létre, amely nem érinti a közzétett verziót, az eseményindítókat és a futásokat;
az automations_update_draft csak olyan piszkozatot módosít, amelyet még senki nem tett közzé; az alkalmazás szerkesztőjében félkész piszkozatot nem írja felül;
a piszkozat az Automatizálás menüpontban jelenik meg, mint bármely más félkész javaslat, és bekapcsolni, közzétenni vagy elindítani csak egy ember tudja az alkalmazásban, jóváhagyási jogosultsággal;
az automations_revision_create_draft egy közzétett, akár bekapcsolt automatizálás módosítását revízióként javasolja; a futó verzió nem változik, amíg egy ember be nem tölti a revíziót a szerkesztőbe és közzé nem teszi (automations_revision_update_draft, automations_revision_discard_draft).

A szerkesztőben listából kiválasztható mezők értékeit (rendelés állapota, szállítási mód, fizetési mód, reklamáció állapota…) az automations_options adja vissza abban a formában, ahogyan a szerkesztő tárolja őket. A webáruházban nem létező érték és a DOPLNIT_… típusú helyőrző szöveg validálási hiba, nem siker.

A létrehozás a clientRequestId révén idempotens, a módosításhoz expectedVersion szükséges, és mindkettőhöz kell az automations_catalog által adott catalogVersion: az elavult katalógus ütközést jelent, nem csendes írást. Az a javaslat, amely ismeretlen eseményindítóra, hatókörön kívüli webáruházra vagy idegen webhook végpontra hivatkozik, nem kerül mentésre. Részletek az MCP interfész oldalon.

Elérhetőségek: módosítási javaslat, amelyet ember hagy jóvá

Az elérhetőségek egy adott webáruház listájának tételei, amelyeket a webáruház a termék mellett megjelenít, például Készleten, Rendelésre vagy Előrendelés: név, leírás, raktárra érkezés és kézbesítés órákban, jelentés a Google Shopping számára és szín. Ez nem a készletszint.

Az availabilities_list és a GET /availabilities?market= (hatókör: products:read) egyetlen webáruház listáját adja vissza; a market kötelező. A manageable mező megmondja, hogy az adott webáruház listája módosítható-e a MitoOps-ból, a reason pedig azt, hogy miért nem: PLATFORMA (a platform nem támogatja), BEZ_ROZSIRENIA (a WooCommerce webáruházból hiányzik a MitoOps bővítmény) vagy PROSTREDIE (a webáruházakba írás ebben a környezetben ki van kapcsolva).
Az availabilities_change_draft (csak MCP, érzékeny hatókör: availabilities:draft) a webáruházba semmit nem ír. Ellenőrzi a módosítást, 24 órán át érvényes javaslatként menti, és visszaadja az előnézetet (minden mező előtte és utána, figyelmeztetések, blokkolások), a draftId és az approvalUrl értékét.
A javaslatot csak egy ember az alkalmazásban írja be a webáruházba a Jóváhagyás és írás gombbal a Raktár → Elérhetőségek → Kezelés oldalon, vagy elutasítja. Ekkor a kattintás pillanatában érvényes jogosultságai döntenek, nem a kulcs vagy a hozzájárulás hatóköre. Sem a modell, sem a hozzáférési kulcs nem ír semmit a webáruházba ember nélkül.
Az availabilities_draft_get és a GET /availabilities/drafts/:draftId (hatókör: products:read) a javaslat állapotát adja vissza: pending, writing, executed, partial, failed, rejected vagy expired.

Az availabilities:draft hatókört a rendszer csak annak az embernek kínálja fel, aki a módosítást jóvá is hagyhatná (a készletszinkronizálás kezelésére és a termékek szerkesztésére vonatkozó jogosultság). A meglévő kulcs vagy hozzájárulás nem örökli. A REST v1 továbbra is csak olvasható. A javaslat paraméterei az MCP interfész oldalon, a jóváhagyási képernyő az Elérhetőségek útmutatóban található.

Reklamációk: beállítások olvasásra és módosítási javaslat

A claims_settings (hatókör: claims:read) visszaadja a folyamatokat a típusok, lépések és állapotok azonosítóival és neveivel, valamint a címkéket; a claims-settings:read hatókörrel a modul beállításait is.
A claims_templates és a claims_configuration (hatókör: claims-settings:read) visszaadja az e-mail- és jegyzőkönyvsablonokat (tárgy, szöveg, mikor és automatikusan küldődnek-e) és a többi beállítást: címkék, mezők, visszaszállítás és a webáruházi űrlap, az integrációs token nélkül.
A claims_get az ügy idővonalát, az elküldött e-maileket és a címkéket is tartalmazza; az üzenetek szövegét csak personal-data:read mellett.
A claims_config_change_draft (csak MCP, érzékeny hatókör: claims-settings:draft) a beállításokat nem módosítja. A folyamatok, állapotok, címkék és sablonszövegek módosítási javaslatát 72 órára menti előnézettel és approvalUrl értékkel; csak a beállítások kezelésére jogosult ember írja be a Jóváhagyás és mentés gombbal a Reklamációk → Beállítások oldalon, teljes egészében vagy egyáltalán nem. Az állapotot a claims_config_draft_get adja vissza.

A paraméterek az MCP interfész oldalon találhatók.

Visszaszállítás, termékszövegek és önálló írás

A claims_routes (claims-settings:read hatókör, vagy bármelyik reklamációs javaslati hatókör) visszaadja a visszaszállítási útvonalakat, a címzett címeit, a futárprofilokat azonosítóval, visszaküldési jelzővel és lefedettséggel, valamint az ügytípusok kulcsait. A claims_routes_change_draft (csak MCP, érzékeny claims-routes:draft hatókör) útvonal létrehozását, módosítását, be- vagy kikapcsolását javasolja. A szerver ugyanúgy ellenőrzi, mint a képernyő: engedélyezett visszaküldésű profil, futár lefedettsége, létező cím és típusok, nem negatív ár, és nincs ütközés bekapcsolt útvonallal. Útvonal törlése MCP-n keresztül nincs.
A products_content_get és a GET /products/:code/content?market= (product-content:read hatókör) a termék leírását, rövid leírását és SEO-szövegeit adja vissza közvetlenül a webshopból, minden mezőt lenyomattal (hash) és azzal, hogy a platform tudja-e írni. A categories_content_get és a GET /categories/:guid/content?market= (category-content:read hatókör) ugyanezt adja vissza kategóriára.
A products_content_change_draft és a categories_content_change_draft (csak MCP, érzékeny product-content:draft és category-content:draft hatókör) új szövegeket javasol, egyszerre legfeljebb 30 tételt. Csak tartalmi mezőket fogadnak el; árat, készletet, elérhetőséget, kódot, EAN-t vagy nevet így nem módosíthat. A HTML ellenőrzött: egy JSON-LD FAQPage blokkon kívül nincs szkript, nincs on…, javascript: vagy iframe. Jóváhagyáskor a szöveget összeveti a webshop állapotával, és ha közben valaki módosította, semmi sem íródik be (CHANGED_SINCE_DRAFT). Ha a webshop mentéskor módosítja a szöveget, az eredmény jelzi (MODIFIED_BY_PLATFORM). A javaslatokat a Raktár → Termékváltozások alatt kell jóváhagyni. WooCommerce-en a szkriptet (JSON-LD-t is) vagy fordított perjelet tartalmazó javaslat blokkolva lesz (PLATFORM_STRIPS_SCRIPT, PLATFORM_STRIPS_BACKSLASH): a WordPress mentéskor eltávolítja őket, a maradékot pedig a vásárlók szövegként látnák.
A products_content_policy és a GET /product-content/policy?market= (product-content:read hatókör) a webshop hívása nélkül megmondja, mit tehet a kulcsa a szövegekkel az adott webshopban: olvashat-e (readEnabled) és javasolhat-e (draftEnabled, javaslat csak MCP-n), mely mezőket írja a platform (supportedFields; a WooCommerce SEO-mezői csak SEO-bővítménnyel), a jóváhagyási módot (approvalMode: human, autonomous vagy disabled), és hogy a javaslat magától beíródik-e (autonomousWriteEnabled), a javaslatok korlátait és a lenyomat algoritmusát (sha256). A szüneteltetett webshop, a nem támogatott platform vagy a csak olvasható webshopkulcs a válaszban status és reason, nem hiba. A category mező ugyanezt adja a kategóriákra. A structuredData mező megmondja, megőrzi-e a platform a strukturált adatokat a termékleírásban: WooCommerce-en nem (NOT_SUPPORTED, PLATFORM_STRIPS_SCRIPT; ott a strukturált adatokat a webáruház sablonja kezeli, THEME_MANAGED), Shoptet-en igen (egy FAQPage blokk).
Önálló írás. Alapértelmezés szerint minden javaslatot (reklamációs beállítások és útvonalak, termék- és kategóriaszövegek) csak egy ember ír be jóváhagyással. Egy rendszergazda területenként bekapcsolhatja a Beállítások → API & MCP → Írás AI-n keresztül alatt. A javaslat ekkor azonnal beíródik, ugyanúgy, mint jóváhagyáskor, annak az embernek a nevében, aki az AI-nak hozzáférést adott, és csak ha ennek az embernek éppen most joga van jóváhagyni a változást. Különben a javaslat vár, és a válasz megmondja, miért. A mód minden változása naplózódik.

A meglévő kulcs és hozzájárulás nem örökli az új hatóköröket; új hozzájárulás kell.

Kimenő webhookok

A REST és az MCP igény szerinti olvasás. Ha az Ön rendszerének azonnal tudnia kell egy eseményről (új rendelés, fizetés, állapotváltozás, küldemény, kézbesítés, készletmozgás, számla, reklamáció), kimenő webhookokon keresztül iratkozhat fel rá: a MitoOps rövid, azonosítókat tartalmazó borítékot küld az Ön címére, HMAC-SHA256 aláírással, hiba esetén újrapróbálkozással és a kísérletek naplójával. A részleteket a rendszer ezután REST-en keresztül tölti be.

A feliratkozásokat egy ember hozza létre az alkalmazásban, ugyanazon a képernyőn, ahol a kulcsokat; REST-en és MCP-n keresztül a végpontok csak olvashatók (webhooks:read, titkos kulcs nélkül). A végpont automatizálási lépésként is használható. Részletek a Kimenő webhookok oldalon.

A fiók limitjei

Az API & MCP és a webhookok minden fizetős tarifa részei a Start tarifától felfelé. A tarifák az aktív kulcsok és végpontok számában különböznek, nem abban, hogy mit lehet olvasni:

Tarifa	API & MCP	Aktív hozzáférési kulcsok	Webhook végpontok
Próbaverzió	nem	0	0
Kezdő	nem	0	0
Start	igen	1	5
Növekedés	igen	2	20
Pro	igen	5	50
Egyedi	igen	megállapodás szerint	megállapodás szerint

A limiteket a szerver érvényesíti: a limit feletti további kulcs vagy végpont létrehozási kísérletét magyarázattal elutasítja. A kulcs cseréje és a végpont titkos kulcsának rotálása nem foglal helyet. A tarifa csökkentése a meglévő kulcsokat és végpontokat nem szünteti meg: csak újat nem lehet létrehozni, amíg a számuk az új felső határ alá nem csökken. Az OAuth-on keresztüli csatlakozás nem használ fel kulcsot.

A fiók aktuális értékeit a kihasználtsággal együtt (aktív automatizálások, havi futások, e-mailek, kreditek) az account_entitlements / GET /account/entitlements adja vissza az account:read hatókörrel. Csak a tarifát, a funkciókat és a limiteket tartalmazza, számlázási adatok nélkül. Az aktuális árlista a mitoops.com/en/cennik oldalon található.

Hívási korlátok

Korlát	Mire vonatkozik	Mennyi
hitelesítés előtt	arra a címre, ahonnan hív	300 hívás / 60 s
hitelesítés után	az adott kulcsra	600 hívás / 60 s

Az első a kulcsok kitalálását akadályozza meg, a második az Öné, és senkivel sem osztozik rajta. A túllépés 429 választ jelent RateLimit-* fejlécekkel. Ez nem tarifaegység: a hívások számáért nem számolunk fel díjat.

Hibák

Hiba esetén a válasz mindig ugyanolyan formájú, és kódot tartalmaz:

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

Állapot	Kód	Mikor
`400`	`invalid_request`	a paraméter nem felel meg a leírásnak (hibás dátum, fordított időszak, érvénytelen kurzor)
`400`	`store_required`	webáruház adataira vonatkozó hívás `market` nélkül
`401`	`unauthorized`	hiányzó, ismeretlen, visszavont vagy érvénytelen kulcs
`403`	`forbidden`	a kulcs nem rendelkezik a szükséges hatókörrel
`403`	`store_forbidden`	a webáruház kívül esik a kulcs hatókörén
`404`	`not_found`	a rekord nem létezik (akkor is, ha másik webáruházhoz tartozik)
`405`	nincs	bármely `GET`-től eltérő kérés (REST)
`409`	`conflict`	a piszkozat írása másik verzióba, már felhasznált `clientRequestId` értékbe vagy megváltozott katalógusba ütközött (MCP)
`429`	`rate_limited`	túllépett technikai hívási korlát

A 401 elutasítás oka nincs megkülönböztetve: a különbség annak segítene, aki kulcsokat próbál kitalálni. A requestId értéket adja meg, amikor problémát jelez az ügyfélszolgálatnak. MCP-n keresztül az asszisztens által javítható hiba eszközeredményként érkezik isError jelzővel, a protokollhiba pedig JSON-RPC hibaként.

Példák

# Rendelések egy időszakra, oldalanként
curl -H "Authorization: Bearer <az Ön kulcsa>" \
  "https://<az Ön címe>/api/v1/orders?market=sk&from=2026-08-01&to=2026-08-31&limit=50"

# Kézbesítési statisztikák augusztusra
curl -H "Authorization: Bearer <az Ön kulcsa>" \
  "https://<az Ön címe>/api/v1/shipping/stats?market=sk&from=2026-08-01&to=2026-08-31"

# Reklamációs statisztika augusztusra
curl -H "Authorization: Bearer <az Ön kulcsa>" \
  "https://<az Ön címe>/api/v1/claims/statistics?market=sk&from=2026-08-01&to=2026-08-31"

# A fiók tarifája és limitjei a kihasználtsággal
curl -H "Authorization: Bearer <az Ön kulcsa>" \
  "https://<az Ön címe>/api/v1/account/entitlements"

Kérdések, amelyekre a Claude.ai csatlakozás után a MitoOps adataiból válaszol: „Mennyi volt a DHL és a GLS kézbesítési idejének mediánja augusztusban?”, „Hány rendelés érkezett a ChatGPT-ből?”, „Mekkora az X termék árrése az elmúlt hónapban?” (purchase-prices:read mellett), „Hány reklamáció van határidőn túl?”, „Kérek egy automatizálást, amely a ki nem fizetett rendelésnél három nap után emlékeztetőt küld” (automations:write mellett kikapcsolt piszkozat jön létre), „Az SK webáruházban a Rendelésre elérhetőség új neve legyen: 5 napon belül” (availabilities:draft mellett javaslat jön létre, amelyet Ön az alkalmazásban jóváhagyással ír be).

Biztonság

Az ügyfélfiókok elkülönítése. Az ügyfélfiók kizárólag a hitelesítő adatból derül ki; minden ügyfélfióknak saját adatbázisa van.
A webáruházak hatóköre a hitelesítő adatban szereplő lista és az adott pillanatban csatlakoztatott webáruházak metszete. Egyetlen webáruház adataira vonatkozó hívásoknál a market kötelező: a hiányzó webáruház 400, a hatókörön kívüli webáruház 403.
Az ember jogosultságai. A hozzájárulási képernyő csak azokat a hatóköröket kínálja fel, amelyekkel a bejelentkezett ember maga is rendelkezik; a fiók saját jogosultságkészlete dönt.
Az írási műveletek határait a szolgáltatás kényszeríti ki, nem az annotáció: az automatizálási piszkozat mindig kikapcsolt állapotban jön létre, a közzétett automatizálás MCP-n keresztül nem módosul, és az elérhetőségek módosítási javaslata semmit nem ír a webáruházba, amíg egy ember jóvá nem hagyja az alkalmazásban.
Érvényesség és visszavonás. Az OAuth hozzáférési token egy óráig érvényes, a frissítő token 30 napig; a visszavont hozzájárulás minden belőle származó tokent leállít. A kulcsok azonnal visszavonhatók vagy lecserélhetők.
Audit. Minden hívás rögzítésre kerül a képesség nevével, az interfésszel és a bemenet ujjlenyomatával, értékek nélkül.
Amire nem lehet támaszkodni: az alkalmazás nem nyilvános címei (az interfész a /api/v1 és a /api/mcp, semmi más), a közvetlen adatbázis-hozzáférés (nem létezik) és a hozzáférési adatok (az interfész nem adja ki őket).