Webshop integráció a Clearvis.io API-val

Ez az útmutató azoknak a fejlesztőknek szól, akik webáruházat (WooCommerce, Shopify, egyedi bolt, …) kapcsolnak a Clearvis.io-hoz. Lefedi a teljes kört: termékek, árak és készlet kiolvasása a Clearvis.io-ból, valamint vevők és rendelések visszaírása.

információ

Kinek szól. Webfejlesztőknek és integrátoroknak. Az itt leírt minden művelet HTTP kérésekkel történik a vevő saját Clearvis.io példányán — a Clearvis.io oldalon a technikai felhasználó létrehozásán túl nincs szükség változtatásra.

Áttekintés

A Clearvis.io egy REST API-t (JSON-LD / Hydra, OpenAPI dokumentációval) és egy GraphQL végpontot biztosít. Mindkettő az előfizetés saját példányának /apiV2 útvonala alatt érhető el:

https://clearvis.io/<subscription name>/apiV2

Amiben az API erős:

Termékkatalógus olvasása — termékek, kiszerelések, vonalkódok és aktuális árak
Készlet olvasása üzletenként, egy megadott időpontra
Vevők létrehozása és frissítése, beleértve a hozzájárulásokat
Webshopban leadott rendelések beküldése, kontaktlencse-rendelésekkel együtt
Számlázás egy beküldött rendelésre és a számla PDF letöltése

Amire nem való:

A teljes katalógus tömeges exportja minden szinkronnál. Egy központi katalógusfrissítés tízezres nagyságrendű terméket is érinthet. Egyszer töltsön be mindent, utána csak a változásokat kérje le.
Valósidejű készlet a pénztárnál. A készletet a Clearvis.io oldala válaszolja meg, és a kiolvasás nem foglal. „Nemrég friss, megbízható” információként kezelje, ne zárolásként.
Szemüvegrendelések összeállítása (keret + lencse + illesztési adatok). Ez az üzletben, az alkalmazásban történik.

1. Technikai felhasználó létrehozása

A technikai felhasználó olyan felhasználó, aki jelszóval nem tud bejelentkezni, és csak API-kulcsa van. Egyébként úgy viselkedik, mint egy normál munkatárs: eléri azokat az üzleteket, amelyekhez hozzáadták, a számára megadott jogosultságokkal.

Az alkalmazásban: Főmenü → Munkatársak → Új technikai felhasználó. Az API‑kulcs a technikai felhasználó saját oldalán jelenik meg, ahol újragenerálható is.

Lásd: Munkatársak → Technikai felhasználó bejelentkezése a lépésről lépésre leíráshoz.

vigyázat

A technikai felhasználót minden olyan üzlethez hozzá kell adni, amelyet az integrációnak el kell érnie, és rendelkeznie kell a végrehajtandó műveletekhez szükséges jogosultságokkal. Egy token önmagában nem elég.

2. Hitelesítés

Minden kérés a technikai felhasználó API‑kulcsát hordozza:

Header	Mikor
`X-AUTH-API-TOKEN`	mindig — az érték a technikai felhasználó API‑kulcsa
`X-AUTH-API-STORE-CODE`	ha a technikai felhasználó egynél több üzlethez van hozzárendelve

Melyik üzlet nevében jár el a kérés

Az üzlet dönti el, mit lát és mit érint a kérés — mely készlet látszik, melyik üzletben jön létre a rendelés.

Technikai felhasználó pontosan egy üzlethez rendelve — azt az üzletet automatikusan használjuk, és az X-AUTH-API-STORE-CODE nem szükséges. Ha mégis elküldi, nem okoz gondot.
Technikai felhasználó több üzlethez rendelve — a fejléc kötelező. Nélküle a kérés 400 hibával és Store was not set üzenettel meghiúsul, mert a Clearvis.io nem tudja kitalálni, melyik üzletre gondol. Ugyanez történik, ha a kód nem egyezik meg egyetlen olyan üzlet kódjával sem, amelyhez a technikai felhasználót hozzáadták.

Minden üzlet kódja az üzletnél van beállítva a Főmenü → Üzletek menüpontban, és azok a kódok használhatók, amelyekhez a technikai felhasználót hozzáadták. A GET /apiV2/stores hívás is visszaadja ezeket (az üzletek code mezője).

Ha az integráció csak egyetlen webshopot szolgál ki, a legegyszerűbb beállítás egy olyan technikai felhasználó, amelyet ahhoz az egy üzlethez adtak hozzá — ekkor sehol nincs szükség az üzletkód fejlécére.

curl -s \
  -H "X-AUTH-API-TOKEN: $CLEARVISIO_API_KEY" \
  -H "X-AUTH-API-STORE-CODE: $STORE_CODE" \
  -H "Accept: application/ld+json" \
  "https://clearvis.io/<subscription name>/apiV2/stores"

Kérjen Accept: application/ld+json választ (az alapértelmezett, leggazdagabb forma), vagy Accept: application/json‑t a JSON‑LD boríték nélküli egyszerű JSON‑hoz.

Egy minimális PHP kliens

Minden hívás ugyanaz a kérés más útvonallal és törzzsel, ezért érdemes egyszer becsomagolni. Az alábbi elég az egész útmutató követéséhez, függőség nélkül:

<?php

class ClearvisioApi
{
    private $basePath;
    private $token;
    private $storeCode;

    public function __construct($basePath, $token, $storeCode = null)
    {
        $this->basePath = rtrim($basePath, '/') . '/';
        $this->token = $token;
        $this->storeCode = $storeCode;
    }

    public function get($route, array $params = [])
    {
        return $this->call('GET', $route . ($params ? '?' . http_build_query($params) : ''));
    }

    public function post($route, array $body = [])
    {
        return $this->call('POST', $route, $body);
    }

    public function put($route, array $body = [])
    {
        return $this->call('PUT', $route, $body);
    }

    public function call($method, $route, $body = null)
    {
        $headers = [
            'X-AUTH-API-TOKEN: ' . $this->token,
            'Accept: application/ld+json',
            'Content-Type: application/ld+json',
        ];
        if ($this->storeCode) {
            $headers[] = 'X-AUTH-API-STORE-CODE: ' . $this->storeCode;
        }

        $raw = @file_get_contents($this->basePath . $route, false, stream_context_create([
            'http' => [
                'ignore_errors' => true,
                'method' => $method,
                'content' => $body === null ? null : json_encode($body),
                'header' => implode("\r\n", $headers),
            ],
        ]));

        preg_match('{HTTP/\S*\s(\d{3})}', $http_response_header[0], $match);
        $status = (int) $match[1];
        $result = json_decode($raw, true);

        if ($status !== 200 && $status !== 201) {
            throw new RuntimeException(sprintf(
                'HTTP %d on %s: %s',
                $status,
                $route,
                $result['hydra:description'] ?? $result['detail'] ?? $raw
            ));
        }

        return $result === null ? $raw : $result;
    }
}

$api = new ClearvisioApi('https://clearvis.io/<subscription name>/apiV2/', getenv('CLEARVISIO_API_KEY'));

A harmadik paramétert hagyja el, amíg a technikai felhasználó egyetlen üzlethez tartozik; több üzlet esetén adja meg az üzletkódot. Az alábbi példák curl‑lal vannak megadva, de egy az egyben lefordíthatók $api->get(...) / $api->post(...) hívásokra.

megjegyzés

A file_get_contents függőségmentesen tartja a példát, de minden hívásnál új kapcsolatot nyit, és nincs saját időkorlátja. Több ezer termék éjszakai szinkronjához használjon cURL‑t megosztott fogantyúval, csatlakozási időkorláttal és 429 esetén újrapróbálkozással.

3. Interaktív dokumentáció

A teljes, mindig aktuális végpontlista minden példányon közzé van téve, és bejelentkezés nélkül olvasható:

URL	Mi ez
`https://clearvis.io/<subscription name>/apiV2/docs`	Swagger UI — böngészhető, „Try it out” funkcióval
`https://clearvis.io/<subscription name>/apiV2/docs.json`	a nyers OpenAPI specifikáció
`https://clearvis.io/<subscription name>/apiV2/docs.jsonld`	a Hydra API‑dokumentáció, JSON‑LD formátumban

A docs.json használható kliens generálásához vagy az API Postman/Insomnia importjához.

A Swagger UI oldalon kattintson az Authorize gombra, és illessze be az API‑kulcsát az apiToken mezőbe. Ettől kezdve a „Try it out” minden kéréshez elküldi a tokent.

megjegyzés

Az Authorize párbeszédablak csak az API‑kulcsot kezeli. Ha a technikai felhasználó több üzlethez van hozzárendelve, a „Try it out” 400 Store was not set hibát ad, mert ebből a párbeszédből nem állítható be az üzletkód fejléce — ezekhez a hívásokhoz használjon curl‑t, Postmant vagy Insomniát, vagy próbálja meg egyetlen üzlethez rendelt technikai felhasználóval.

vigyázat

A dokumentációs oldal egy éles példány szolgáltatása. A „Try it out” ténylegesen végrehajtja a kérést — egy PUT egy vevőn lecseréli annak adatait, egy POST a /apiV2/orders végpontra pedig valódi rendelést hoz létre. Felfedezéshez használjon teszt‑előfizetést.

Az oldal az alkalmazás minden végpontját listázza, függetlenül attól, ki nézi. Hogy egy adott művelet ténylegesen elérhető‑e, a jogosultságaitól és az előfizetési csomagtól függ — lásd: Hibaválaszok.

4. Kérésszám-korlát (rate limit)

Az X-AUTH-API-TOKEN fejlécet hordozó kérések kliens IP‑címenként vannak korlátozva:

240 kérés / 60 másodperc alapértelmezetten
a limit a bolthálózat méretével skálázódik: megszorozzuk ceil(üzletek száma / 5) értékkel

Minden válasz visszajelzi az aktuális állapotot:

X-RateLimit-Limit: 240
X-RateLimit-Remaining: 238
X-RateLimit-Reset: 1785930606

Az X-RateLimit-Reset Unix‑időbélyeg. Ha az időkeret kimerül, az API 429 Too Many Requests választ ad. Figyelje az X-RateLimit-Remaining értékét, és ütemezze a szinkront ahelyett, hogy a korlátba újrapróbálkozna.

5. Termék‑ és ár‑szinkronizáció

curl -s \
  -H "X-AUTH-API-TOKEN: $CLEARVISIO_API_KEY" \
  -H "X-AUTH-API-STORE-CODE: $STORE_CODE" \
  -H "Accept: application/ld+json" \
  "https://clearvis.io/<subscription name>/apiV2/products?type=Sunglasses"

A gyűjtemények lapozottak; a következő oldal kérhető a ?page=2 paraméterrel. A teljes elemszámot a hydra:totalItems adja meg.

Egy termék tartalmazza a saját kiszereléseit, és minden kiszerelés tartalmazza a vonalkódjait és az aktuális árakat:

{
  "@id": "/<subscription name>/apiV2/products__sunglasses/1",
  "@type": "Products_Sunglasses",
  "name": "Sample sunglasses",
  "code": "CH-1",
  "state": 2,
  "packagings": [
    {
      "@id": "/<subscription name>/apiV2/packagings/1",
      "code": "CH-1",
      "unit_of_measure": "pc",
      "barcodeStrings": ["0400000000015"],
      "currentPrices": [
        {
          "valid_from": "2024-11-27T00:00:00+01:00",
          "valid_until": "3017-05-15T23:59:59+01:00",
          "value": 16000,
          "b2b_value": null
        }
      ]
    }
  ],
  "updated": "2024-11-27T17:20:56+01:00"
}

A kiszerelés az, amit ténylegesen értékesítünk, és amin a készletet tartjuk — egy termékből több kiszerelés is lehet.

A state jelzi, hogy a termék forgalomban van‑e:

`state`	Jelentés
`0`	nincs forgalomban
`1`	értékesíthető
`2`	értékesíthető és megrendelhető

Hasznos termékszűrők

Szűrő	Cél
`type`	vesszővel elválasztott terméktípusok, pl. `Sunglasses,Frame,ContactLens`
`updated[after]`, `updated[strictly_after]`	csak a megadott dátum óta változott termékek — ez az inkrementális szinkron
`updated[before]`, `updated[strictly_before]`	a másik irány
`tag_connections.tag.name`	csak egy adott címkével rendelkező termékek
`state`	szűrés a fenti állapotok szerint
`code`, `nameExact`, `packagings.code`, `packagings.barcodes.code`	pontos keresések; több értékhez ismételje `[]`‑tel, pl. `?code[]=LA-214629&code[]=ZE-214626`
`search`	bármely név‑, kód‑ vagy vonalkódrészlet
`page`	oldalszám

Ajánlott szinkronstratégia

Kezdeti betöltés — lapozza végig azokat a terméktípusokat, amelyeket értékesít. Ezt egyszer, munkaidőn kívül végezze.
Éjszakai inkrementális — ismételje meg updated[after]=<utolsó sikeres szinkron> paraméterrel. Ez jellemzően csak néhány terméket érint, és bőven 1 másodperc alatt válaszol.
Címkézze fel, mit árul a webshop. Hozzon létre termékcímkét az alkalmazásban, tegye rá a webshopba tartozó termékekre, és szűrjön erre:
```
/apiV2/products?tag_connections.tag.name=Webshop&updated%5Bafter%5D=2026-08-01
```
A meglévő címkék a /apiV2/product_tags végponton érhetők el.

vigyázat

Ne kérje le a teljes katalógust egyetlen, szűretlen kérésben. Egy bolthálózati katalógus bőven meghaladhatja a százezres termékszámot, és egy elég régi updated[after] dátum mindegyikre illeszkedhet — a kérés egyszerűen időtúllép. Mindig kombinálja a dátumszűrőt címkével vagy típussal, és kövesse a lapokat.

6. Készlet

curl -s \
  -H "X-AUTH-API-TOKEN: $CLEARVISIO_API_KEY" \
  -H "X-AUTH-API-STORE-CODE: $STORE_CODE" \
  -H "Accept: application/ld+json" \
  "https://clearvis.io/<subscription name>/apiV2/stocks?storeCode=DO&dateTime=2026-08-05"

Szűrő	Megjegyzés
`dateTime`	kötelező — az az időpont, amelyre a készletet kérdezi. `YYYY-MM-DD` vagy teljes ISO 8601 érték időzóna‑eltolással (`2026-08-05T12:00:00+0200`)
`storeCode` vagy `store`	melyik üzlet készlete; a kettő közül az egyik kötelező
`updatedSince`	csak az adott dátum óta változott készlet
`minQuantity`	csak a megadott mennyiséget elérő vagy meghaladó készlet
`packaging`	kiszereléskód vagy IRI; több is adható vesszővel elválasztva
`productTypes`	vesszővel elválasztott terméktípusok, lásd lejjebb
`page`	oldalszám

Minden találat egy kiszerelésre válaszol, két külön jelentésű mennyiséggel:

{
  "@type": "Stock",
  "packaging": { "@id": "/<subscription name>/apiV2/packagings/1", "code": "CH-1" },
  "store": { "@id": "/<subscription name>/apiV2/stores/1" },
  "availableQuantity": 3,
  "inventoryQuantity": 4
}

availableQuantity — szabad készlet, amit még el lehet adni. A már vevői rendeléshez lekötött tételek nincsenek benne.
inventoryQuantity — fizikai készlet, ami a polcon van.

Webshop számára jellemzően az availableQuantity a publikálandó. A minQuantity negatív értéket is elfogad, így pl. a minQuantity=-1000 a negatívba fordult kiszereléseket is visszaadja.

A productTypes a következőket fogadja, vesszővel elválasztva, Products_ előtaggal vagy anélkül:

ContactLens, ContactLensVariant, ContactLensSolution, EyeDrops, Frame, Sunglasses, Lens, LensVariant, LensService, AggregateLens, CylExtraCharge, PrismExtraCharge, Misc, Service

vigyázat

A dateTime elhagyása 400 választ ad Date time filter should be set üzenettel, időzóna‑eltolás nélküli érték pedig 400 választ Invalid date format üzenettel. Használja az egyszerű YYYY-MM-DD formát, hacsak nem valóban a napon belüli pillanatra van szüksége.

Ismeretlen terméktípus esetén 400 Invalid product types — és a teljes kérés elbukik, nem csak az az egy érték. Figyeljen a többes számra az EyeDrops esetén.

Az első teljes betöltés után adjon meg updatedSince értéket, hogy csak a változások érkezzenek vissza.

7. Rendelés beküldése

A rendelés beküldése egy rövid lánc, mert a rendelés a Clearvis.io azonosítóival hivatkozik az entitásokra.

7.1 Először a vevő

Küldje be (vagy keresse meg) a vevőt, és jegyezze fel a visszakapott azonosítót:

curl -s -X POST \
  -H "X-AUTH-API-TOKEN: $CLEARVISIO_API_KEY" \
  -H "X-AUTH-API-STORE-CODE: $STORE_CODE" \
  -H "Content-Type: application/ld+json" \
  -H "Accept: application/ld+json" \
  -d '{"first_name":"Jane","last_name":"Doe","country":"HU"}' \
  "https://clearvis.io/<subscription name>/apiV2/customers"

A válasz tartalmazza a vevő @id értékét, például /<subscription name>/apiV2/customers/1 — erre az IRI‑re hivatkozik majd a rendelés.

vigyázat

A PUT egy vevőn lecseréli a vevő összes adatát. Olvassa ki előbb a vevőt, és a teljes képet küldje vissza, különben a bolt által kitöltött mezőket törli.

Normál, nem API‑s használatban a Clearvis.io megkéri az üzletet, hogy a vevő hozzájárulásait írassa alá — például a vizsgálati adatok tárolásához, marketinganyagok fogadásához stb. Ha a webshop már begyűjtötte ezeket, küldje be Ön is, és az üzlet nem fogja újra kérni:

{
  "customer": "/<subscription name>/apiV2/customers/1",
  "medical_records_allowed": true,
  "document_emailing_allowed": true,
  "marketing_email": true,
  "email": "jane@example.com",
  "approved_at": "2026-08-07",
  "source": "api"
}

Ezt POST‑olja a /apiV2/customer_consents végpontra. Címkés hozzájárulásokhoz ott a /apiV2/customer_consents/createForTag is.

7.2 A rendelés ezután

curl -s -X POST \
  -H "X-AUTH-API-TOKEN: $CLEARVISIO_API_KEY" \
  -H "X-AUTH-API-STORE-CODE: $STORE_CODE" \
  -H "Content-Type: application/ld+json" \
  -H "Accept: application/ld+json" \
  -d '{
    "customer": "/<subscription name>/apiV2/customers/1",
    "status": 1,
    "options": [{
      "selected": true,
      "order_lines": [{
        "@type": "OrderLines_MiscOrderLine",
        "packaging": "/<subscription name>/apiV2/packagings/1",
        "quantity": 1,
        "procurement": 1,
        "pricing_line": {
          "price": "16000",
          "discount_lines": [{
            "discount": {"@id": "/<subscription name>/apiV2/discounts/1"},
            "value": "5000"
          }]
        }
      }]
    }]
  }' \
  "https://clearvis.io/<subscription name>/apiV2/orders"

Siker esetén 201 Created választ kap a teljes rendelésobjektummal, beleértve az @id‑jét és az ajánlat @id értékét is — utóbbit őrizze meg, ha a rendelést ezután számlázni szeretné.

A fenti rendelés egy kiszerelést ad el 16 000‑ért, rajta 5 000 kedvezménnyel. Az elérhető kedvezmények a /apiV2/discounts végponton érhetők el; a value a levont összeg.

A kiszerelésre hivatkozzon, ne a termékre: ezen a szinten él a készlet és az ár, és ezt adta vissza a készletvégpont is. Egy sor megnevezhet product mezőt is — a Clearvis.io ekkor maga tölti ki a kiszerelést, ami csak addig egyértelmű, amíg a terméknek pontosan egy kiszerelése van.

Rendelés status:

Érték	Jelentés
`0`	új
`1`	kész

Tételsor procurement — mi történjen a készlettel:

Érték	Jelentés
`-1`	nincs készletmozgás
`0`	lefoglalás készletről
`1`	megrendelés

Tételsor @type — webshopos rendelésekhez használja az OrderLines_MiscOrderLine típust: napszemüvegek, önmagukban eladott keretek, ápolófolyadékok, kiegészítők. A kontaktlencsének külön sora van, lásd lejjebb.

vigyázat

Az API elfogadja az OrderLines_FrameOrderLine, OrderLines_LensOrderLine és egyéb szemüveges tételtípusokat is, de ezek egy olyan szemüvegrendeléshez tartoznak, amelyet az üzletben állítanak össze a lencsesorokkal és az illesztési adatokkal együtt. Webshopból beküldve olyan rendelést hozna létre, amelyet az üzlet nem tud befejezni. Maradjon az OrderLines_MiscOrderLine típusnál.

7.3 Kontaktlencse‑rendelések

A kontaktlencséket szemenként adjuk el, ezért a rendelés oldalanként egy sort visz, mindegyiken a lencseparaméterekkel:

{
  "customer": "/<subscription name>/apiV2/customers/1",
  "status": 1,
  "options": [{
    "selected": true,
    "order_lines": [
      {
        "@type": "OrderLines_ContactLensOrderLine",
        "side": 0,
        "packaging": "/<subscription name>/apiV2/packagings__contact_lens_variant_packagings/125",
        "quantity": 1,
        "procurement": 1,
        "sph": "5.5",
        "curvature": "8.6",
        "diameter": "14.0",
        "pricing_line": {"price": "5000"}
      },
      {
        "@type": "OrderLines_ContactLensOrderLine",
        "side": 1,
        "packaging": "/<subscription name>/apiV2/packagings__contact_lens_variant_packagings/125",
        "quantity": 1,
        "procurement": 1,
        "sph": "5.5",
        "curvature": "8.6",
        "diameter": "14.0",
        "pricing_line": {"price": "5000"}
      }
    ]
  }]
}

A side értéke 0 a jobb szemhez és 1 a balhoz. Tórikus lencséknél cyl és axis is kell — mindig együtt.

A kiszerelés egy kontaktlencse‑változatról érkezik: egy változat egy konkrét paraméter‑kombináció, ezért keresse meg /apiV2/products?type=ContactLensVariant hívással, code vagy packagings.code szűrővel, és vegye át róla a kiszerelést.

megjegyzés

A rendelés recept nélkül is működik, de ekkor sima rendelésként kerül iktatásra, nem kontaktlencsésként. Recept az ajánlatban küldhető prescription mezőként, típusa Prescriptions_ContactLensPrescription (vagy Prescriptions_MultifocalContactLensPrescription), a vevővel, a szemenkénti paraméterekkel és purpose mezővel 1 (rendszeres) vagy 2 (alkalmi) értékkel.

8. Rendelés számlázása

Egy rendelési ajánlat API‑n keresztül is számlává alakítható. A lánc négy hívásból áll:

Számlafizető cím létrehozása — kinek a nevére szól a számla:

{
  "taxable": 1,
  "name": "Jane Doe",
  "country": "HU",
  "postal_code": "2100",
  "city": "Gödöllő",
  "street_address": "Teszt utca 18"
}

POST a /apiV2/payer_addresses végpontra, jegyezze fel az @id‑t.

Fizetés létrehozása — POST a /apiV2/payments végpontra:
```
{"subtype": "invoice", "client": {"address": {"@id": "/<subscription name>/apiV2/payer_addresses/4"}}}
```
Visszatéréskor a "status": "pending" szerepel benne.
Ajánlat hozzácsatolása — PUT a /apiV2/payments/{id}/addOrderOption végpontra {"orderOption": "/<subscription name>/apiV2/order_options/21"} törzzsel. A válasz most már tartalmazza az összegeket és az ÁFA összesítést. Van /apiV2/payments/{id}/addProductPackaging is közvetlen kiszerelés számlázásához, rendelés nélkül.
Kiállítás — PUT a /apiV2/payments/{id}/issue végpontra. A válasz fulfilledAt mezőt és a paymentId emberi olvasatú azonosítót (számlaszámot) kapja.

A PDF ezután egy egyszerű GET a /apiV2/payments/{id}/pdf végpontra, application/pdf válasszal.

vigyázat

A kiállítás API‑ból nem visszavonható — valódi számlát állít ki valódi számlaszámmal, az előfizetés által használt számlázási integráció alatt. Gyakoroljon teszt‑előfizetésen.

Hibaválaszok

Állapot	Mikor	Törzs
302	nincs `X-AUTH-API-TOKEN` fejléc	átirányítás a bejelentkezési oldalra — nem JSON hiba. Ha HTML‑t kap vissza, hiányzik a token fejléc
400	hiányzik az `X-AUTH-API-STORE-CODE`, vagy ismeretlen üzletkód	`Store was not set`
400	kötelező szűrő hiányzik vagy hibás	pl. `Date time filter should be set`
402	az előfizetési csomag nem tartalmazza a szükséges funkciót	`This feature is not available in your context`
403	ismeretlen token, vagy a tokenhez tartozó felhasználónak nincs jogosultsága	`You are not allowed to view.` / `...create.` / `...edit.` / `...delete.`
429	kimerült a kérési keret	lásd: Kérésszám‑korlát (rate limit)

információ

A 402 szokott meglepetést okozni. Nem jogosultsági probléma, a token újragenerálása nem segít — az előfizetés csomagja egyszerűen nem tartalmazza az adott funkciót. Ezt az előfizetésen kell rendezni, nem az integrációban.

Korlátok és tudnivalók

A készlet kiolvasása nem foglal. Két webshopos rendelés is érkezhet ugyanarra az utolsó darabra. A túlértékesítést a webshop oldalon kezelje.
Az árak kiszereléshez kötöttek és időben érvényességi sávval rendelkeznek (valid_from / valid_until). Minden szinkronnál olvassa újra őket, ne tárolja végtelen ideig gyorsítótárban.
Az üzletkód dönti el a kontextust. Ugyanaz a kérés másik üzletkóddal másik üzlet készletére válaszol, és másik üzletben hoz létre rendelést.
A szemüvegrendelések hatókörön kívül vannak. Keret plusz lencse plusz illesztési adatok az üzleti munkafolyamat része.
A kérésszám‑korlát kliens IP‑re vonatkozik, nem tokenre. Ugyanazon kimenő IP mögötti több integráció osztozik a kereten.

Segítség

Ha az útmutató valamely állítása nem egyezik az API válaszával, a példány interaktív dokumentációja az irányadó — ez a futó kódból generálódik. Ezen túlmenő kérdésekben lépjen kapcsolatba a Clearvis.io támogatással.

Áttekintés​

1. Technikai felhasználó létrehozása​

2. Hitelesítés​

Melyik üzlet nevében jár el a kérés​

Egy minimális PHP kliens​

3. Interaktív dokumentáció​

4. Kérésszám-korlát (rate limit)​

5. Termék‑ és ár‑szinkronizáció​

Hasznos termékszűrők​

Ajánlott szinkronstratégia​

6. Készlet​

7. Rendelés beküldése​

7.1 Először a vevő​

7.2 A rendelés ezután​

7.3 Kontaktlencse‑rendelések​

8. Rendelés számlázása​

Hibaválaszok​

Korlátok és tudnivalók​

Segítség​

Áttekintés

1. Technikai felhasználó létrehozása

2. Hitelesítés

Melyik üzlet nevében jár el a kérés

Egy minimális PHP kliens

3. Interaktív dokumentáció

4. Kérésszám-korlát (rate limit)

5. Termék‑ és ár‑szinkronizáció

Hasznos termékszűrők

Ajánlott szinkronstratégia

6. Készlet

7. Rendelés beküldése

7.1 Először a vevő

7.2 A rendelés ezután

7.3 Kontaktlencse‑rendelések

8. Rendelés számlázása

Hibaválaszok

Korlátok és tudnivalók

Segítség