Új API, kiterjesztett ellenőrzés, friss Kézi lekérdező, frissülő WooCommerce bővítmény, új client library, rendszer optimalizálás – 2024. december

Ma nálunk is járt a Mikulás – nagy zsákkal érkezett, és egy sokatok által és régóta várt fejlesztést hozott ajándékba: elkészült az Utánvét Ellenőr új API-ja! 🥳 Ennek köszönhetően megnyílt a lehetőség, hogy ne csak e-mail cím alapján ellenőrizzük a vásárlókat, valamint az e-mail címes ellenőrzések is hatékonyabbak lesznek! Természetesen ez csak a jéghegy csúcsa és a havi frissítések csak egy része – nézzük is, hogy mi minden változott!

API 2.0 változások

Kiterjesztett ellenőrzés

A legfontosabb, és legtöbbször kért funkció vált elérhetővé az új API-val, melyet már nagyon sokan vártatok: már nem csak e-mail címből generált hash alapján tudtok kérdéseket intézni az API-hoz, de az API kérésben már küldhetitek a szállítási címet és telefonszámot is. További változás, hogy az e-mail címet sem kell hashelnetek a lekérésben, így további ellenőrzéseket tudunk végezni az e-mail címen is.

Nagyon sok kaput megnyit ez a változtatás, én nagyon lelkes vagyok! 🤩 Erre egy példa: nem feltétlenül magától értetődő, de ezzel a fejlesztéssel azokat a vásárlókat is eredményesen lehet szűrni, akik "kamu" e-mail címmel, de változatlan telefonszámmal és ugyanazon a környéken lévő csomagpontokra/automatákba rendelnek csomagot.

Fontos: az adatok tárolásában nem változott semmi, továbbra is hashelve tároljuk a beküldött és lekért e-mail címeket!

Döntések indoklása

Annak érdekében, hogy láthasd, miért blokkoltunk vagy engedtünk át egy-egy ellenőrzést, az API válaszban megjelenik az általunk javasolt döntés indokolása is, melyek jelenleg az alábbiak lehetnek:

  • Test hash was used. – Teszt e-mail címet használtál az ellenőrzéshez.
  • Run out of request quota for current billing period, upgrade your subscription to resolve! – A jelenlegi előfizetési csomag kimerült, vagy nincs aktív előfizetés.
  • Active exception found for this hash in your account. – A fiókodban az adott e-mail cím már szerepel Kivételként.
  • Temporary e-mail was used. – Eldobható e-mail cím.
  • No Signals were found. – Nem találtunk adatot.
  • Total rate did not meet the minimum threshold set. – A vásárló reputációja nem érte el a beállított küszöbértéket.
  • Signals found, checks passed. – Ellenőrzés sikeres, rendben.

További változások, dokumentáció

A dokumentáció és az összefoglaló a változásokról hamarosan felkerül a Tudástárba, összefoglalva a változások az alábbi listában:

  • Kötelezővé vált az `Accept: application/json` header használata
  • A `threshold` kötelező paraméterré vált az ellenőrzési kérésben.
  • Az eddigi `totalRate` mostantól `reputation`.
  • Az API által küldött válaszból kikerült a `goodRate`, `badRate`, mert ezek a többi adat alapján számolható értékek.
  • Változott az endpointok URL-je: az eddigi "egységes" végpont helyett két, POST metódussal hívható végpontot kapott az új API:
  • A válaszba bekerült a blokkolást jelző `blocked` adattag: true esetén elbukta, false esetén átment az ellenőrzésen a vásárló.
  • Az API által adott állapotkódok is bővültek, az eddigi 200 és 404 mellett a körük az alábbiakkal gyarapodott:
    • 202 Accepted: teszt e-mail cím beküldése esetén
    • 204 No Content: eldobható e-mail cím esetén
    • 402 Payment Required: kvóta túllépés/előfizetés hiánya esetén
  • A Forráshoz tartozó fiók e-mail címe automatikusan hibát ad beküldéskor, arra Visszajelzést nem enged beküldeni.

Az új API-t az integrációk fokozatosan kezdik majd el használni, az elérhetőségekről külön értesítőben fogok jelentkezni.

Frissült a Kézi lekérdező

Az integrációk közül elsőként a Kézi lekérdezőben vált elérhetővé a kiterjesztett ellenőrzés lehetősége. Ehhez szükség volt a felület átalakítására is, amit szintén ma délelőtt élesítettem.

Az új API és a kibővített ellenőrzés jelenleg a megszokott csomagokkal, változatlan áron használható.

Jól látható, hogy egy kitalált e-mail cím esetében nincs adatunk, viszont ugyanehhez a vásárlóhoz a kiterjesztett ellenőrzéssel már találunk adatot. 💪

Ha még nem tetted, próbáld ki most a Kézi lekérdezőt!

utanvet-ellenor/client-php

Az új API-hoz jelentősen átdolgoztuk a connector library-t, ami az eddigi `webmenedzser/uvb-connector` helyett mostantól `utanvet-ellenor/client-php` néven érhető el. Ezzel egyidejűleg a `webmenedzser/uvb-connector` állapota a Packagist-ben abandoned lett, további frissítéseket nem fog kapni – a továbbiakban kérlek, használjátok az `utanvet-ellenor/client-php` csomagot.

További változás, hogy a Guzzle a továbbiakban már nem szerepel függőségként, az API kéréseket cURL küldi a kódból, így gyakorlatilag nincs függősége a client library-nek: az egyetlen minimum követelmény a legalább 7.4 vagy 8.0 PHP verziók.

Frissült a WooCommerce plugin

A WooCommerce plugin 3.0.0-ás verziójától kezdődően már az új API-n keresztül folyik az ellenőrzés, egyelőre még a "megszokott" módon, csak e-mail alapúan. Egy későbbi frissítésben érkezik majd a bővített adatokkal történő ellenőrzés. A Rendelések listázó nézetében természetesen már láthatod a fentebb említett indokolást minden rendelés esetében.

Optimalizálás, a rendszer gyorsítása

Októberben és novemberben is sokat dolgoztam a rendszer sebességének a további javításán, az alábbi grafikonokon jól látható, ahogy "megnyugszik" a hardver, és szemmel láthatóan csökkent a terhelése, pusztán néhány optimalizálásnak köszönhetően.

Remélem, hogy az Utánvét Ellenőr az új, kiterjesztett ellenőrzésének köszönhetően még hasznosabb és hatékonyabb eszköze lehet a működéseteknek! Ha bármilyen kérdésed felmerül, vagy észrevételed van, esetleg hibát találtál, keress bizalommal!