Kako v platformo SaaS vključiti API za računovodstvo v oblaku

Vodnik za praktike o gradnji večuporabniške računovodske integracije, ki preživi postopke OAuth, spletne kljukice, davčna pravila in poravnavo, ne da bi poškodovala glavno knjigo.

Večina ekip, ki se odloči za „dodajanje računovodstva“ v svoj izdelek SaaS, začne tako, da odjemalca HTTP poveže s končno točko ponudnika in pošlje račun. To deluje v predstavitvi. Vendar pa odpove ob prvi priložnosti, ko stranka poveže dve računovodski organizaciji, ko spletna kljukica (webhook) prispe dvakrat ali ko se žeton za osvežitev (refresh token) zamenja in med zahtevkom izgubi. Trajna izvedba te naloge ni navaden odjemalec, temveč integracijska plast.

Ta plast mora upravljati povezave najemnikov (tenants), shranjevanje in rotacijo žetonov, računovodska pravila, značilna za posameznega ponudnika, preslikavo zapisov, začetno in postopno usklajevanje, sprejemanje spletnih kljukic s ponovnimi poskusi in preprečevanjem podvajanja, omejitve pogostosti klicev (rate limits), različice in revizijsko sled, ki jo lahko vaša podpora prebere ob dveh ponoči. V tem članku si bomo ogledali to arhitekturo in odločitve, ki so ključnega pomena.

Učinkovit miselni vzorec:

izdelek SaaS → storitev računovodske integracije → prilagojevalnik ponudnika (ali poenoten API) → asinhrono usklajevanje in poravnava

Računovodski sistem ostane vir resnice (system of record) za predmete v glavni knjigi: konte, davčne stopnje, knjižene transakcije in temeljne vknjižbe. Vaša platforma SaaS ohranja stabilne med sistemske identifikatorje, stanje usklajevanja, metapodatke preslikav in operativni revizijski sledilnik.

Kaj tukaj dejansko pomeni „API za računovodstvo v oblaku“

Ta izraz običajno označuje API gostujoče knjigovodske platforme, kot so QuickBooks Online, Xero, Sage, Zoho Books, ali regionalnega sistema. Lahko pa pomeni tudi poenoten računovodski API, ki več ponudnikov poenoti pod vmesnikom.

Natančnost je pomembna, saj se izvedba razlikuje glede na namen. Branje računov za namene poročanja ni isto kot ustvarjanje računov na podlagi dejavnosti v SaaS, knjiženje prejetih računov, usklajevanje strank in izdelkov, vnašanje temeljnih vknjižb ali izvajanje dvosmernega usklajevanja. Preden se dotaknete katere koli končne točke, se odločite, kaj pravzaprav gradite.

Za ta članek je pomembna še ena razlika. Plačilni API premika denar. Bančni API pridobiva podatke o računih. API za izdajanje računov lahko ustvarja dokumente, ne da bi razkril glavno knjigo. Vgrajena računovodska glavna knjiga pa je nekaj povsem drugega: podjetje SaaS je lastnik samega računovodskega mehanizma. Ta zadnji pristop je tisto, kjer se nahaja Nordlet. Namesto da svoj izdelek povezujete z zunanjimi knjigami stranke, Nordlet platformam in tržnicam omogoča pravo dvostavno knjigovodstvo, nespremenljivo glavno knjigo, pripravljeno za revizijo, obravnavo DDV v EU in izplačila znotraj lastnega izdelka prek zasnove, ki temelji na API-ju, s tipiziranimi kompleti SDK in spletnimi kljukicami. Če ste tržnica, ki se odloča, ali naj vključi strankin računovodski sistem ali pa knjige vodite sami, je to resnično križišče, na katero se bomo še vrnili.

Večuporabniškost (multi-tenancy): vsako povezavo opredelite dvakrat

V izdelku SaaS se ena aplikacija povezuje z mnogimi organizacijami strank. Vsaka povezava mora biti opredeljena tako z najemnikom SaaS (SaaS tenant) kot z identifikatorjem organizacije pri ponudniku, kot sta ID najemnika v sistemu Xero ali ID področja (realm ID) v sistemu QuickBooks.

Povezav ne določajte izključno na podlagi ID-ja uporabnika OAuth. Eden uporabnik lahko pooblasti več računovodskih organizacij, posamezno organizacijo pa lahko čez čas znova povežejo različni uporabniki. Če se tukaj zmotite, boste sčasoma račun ene stranke knjižili v knjige druge stranke, to pa je napaka, iz katere se ni mogoče tiho rešiti.

Prva arhitekturna odločitev: neposredni povezovalnik, poenoten API ali vgrajena glavna knjiga

Neposredne integracije s ponudniki

Neposredna integracija vam omogoča največji nadzor: funkcije, specifične za posameznega ponudnika, polja po meri, obravnavo napak, pogostost usklajevanja, hrambo podatkov in cenovno strukturo. Cena za to pa je resnična. Vsak ponudnik prinaša svoj postopek OAuth, shemo, posebnosti, omejitve pogostosti klicev, obnašanje spletnih kljukic, certifikate in tekoče vzdrževanje.

Poenoteni računovodski API-ji

Poenoten API ponuja enoten vmesnik za več računovodskih sistemov ter normalizira entitete, kot so stranke, računi, dobavitelji, konti, plačila, izdelki in storitve. Lahko skrajša čas začetne izdelave. Vendar pa ne odpravlja integracijske kompleksnosti in obravnava tega kot nekaj samoumevnega je pogosta napaka.

Preden se odločite, vprašajte naslednje: Kateri ponudniki in operacije so podprti? Ali pisanje podatkov deluje ali so na voljo samo berljive operacije? Ali so zapisi sinhroni ali v čakalni vrsti? So polja, specifična za ponudnika, dostopna prek prepisovanja (passthrough)? Ali se podatki predpomnijo in kako sveži so? Kdo obravnava izpade ponudnika in spremembe API-ja? Je cenik določen na klic, na povezani račun, na zapis ali kot provizija platforme? Lahko izvozite svoje preslikave in čisto prekinete povezavo? Beseda „poenoten“ le redko pomeni „enakovredne funkcije pri vseh ponudnikih“.

Vgrajena glavna knjiga

Če je osrednji problem vaše platforme vodenje računovodstva za vaše uporabnike in ne njegovo zrcaljenje v njihovih obstoječih knjigah, vgrajena glavna knjiga spremeni izračun. Tržnici s tisoči prodajalcev ali izdelku SaaS, ki potrebuje vgrajen in za revizijo pripravljen sistem za obračun DDV v EU in skladen s predpisi posameznih držav, bolj koristi lastništvo računovodskega mehanizma kot pa povezovanje zunanjih povezovalnikov za N ponudnikov. To je položaj rešitve Nordlet: prave knjige kot API, nespremenljivo dvostavno knjigovodstvo, DDV po državah z preverjanjem VIES in generiranjem registra i.SAF, izvoz SEPA ter izvozi poročil v formatih XLSX, PDF ali JSON, in sicer neposredno v vašem izdelku namesto v zunanjem blagajniškem sistemu.

Pravilo odločanja, ki ga uporabljam:

Situacija	Najboljša izbira
En računovodski ponudnik prevladuje v vaši bazi strank; ključno je obnašanje, specifično za ponudnika	Neposredni povezovalnik
Široka pokritost ponudnikov in hitrost dostopa na trg sta pomembnejša od nadzora	Poenoten API
Ste platforma ali tržnica, ki mora voditi in imeti v lasti knjige, z vključenim DDV v EU in revizijskimi sledmi	Vgrajena glavna knjiga (Nordlet)
Mešano okolje	Hibridna rešitev: poenoteno za pogoste tokove, neposredni povezovalniki za strateške ponudnike

Priporočena arhitektura integracije

Ločite integracijo od osnovne poslovne logike

Klicev ponudnikov ne razpršujte po delih za obračunavanje, naročila, naročnine in poročanje. Zgradite namensko integracijsko storitev, ki vključuje prilagojevalnike ponudnikov, upravljanje povezav OAuth, kanonične modele, preslikave ID-jev, posle in čakalne vrste za usklajevanje, končne točke spletnih kljukic, obravnavo ponovnih poskusov ter zavrženih sporočil (dead-letter), revizijske dnevnike in orodja za poravnavo. S tem preprečite, da bi se imena polj sistemov Xero ali QuickBooks razširila v vaš domenski model.

Opredelite ozek kanonični model

Modelirajte samo delovne tokove, ki jih podpirate. Običajni predmeti: stranka, artikel izdelka ali storitve, račun, postavka računa, plačilo, dobropis, dobavitelj, konto, davčna stopnja, valuta, temeljna vknjižba.

Ohranite razlike, ki vplivajo na računovodstvo. Ne izenačujte osnutkov z odobrenimi ali knjiženimi dokumenti, zneskov z vključenim ali izključenim davkom, dobropisov z negativnimi računi, dodelitve plačil z obstojem plačila ali številke računa za stranko z ID-jem predmeta pri ponudniku. Vsak zapis mora vsebovati ID v SaaS, ID pri ponudniku, ime ponudnika in različico API-ja, kazalnik vira resnice, stanje, časovne žige, čas zadnjega usklajevanja, zunanjo referenco ter stanje napake ali poravnave.

Vzdržujte eksplicitne tabele preslikav

Povežite najemnika SaaS z računovodsko organizacijo, stranko SaaS s stikom pri ponudniku, izdelek SaaS z artiklom ali kontom pri ponudniku, račun SaaS z računom pri ponudniku, plačilo SaaS s plačilom pri ponudniku, davčno skupino z davčno kodo in prihodkovno skupino s kontom v glavni knjigi.

Nikoli ne uporabljajte imen ali e-poštnih naslovov kot trajnih identifikatorjev. Imena se spreminjajo, obstajajo podvojeni vnosi, dve stranki si lahko delita e-poštni naslov. Shranite nespremenljiv ID ponudnika in ohranite izvirni ID v SaaS.

Dodajte stroje stanja (state machines)

Povezavi dodelite eksplicitna stanja: ni povezano, avtorizacija v teku, povezano, začetno usklajevanje v teku, usklajevanje poteka, deluje brez napak, presežena omejitev pogostosti klicev, potrebna ponovna avtorizacija, ponudnik ni dostopen, prekinjena povezava, trajna napaka. Zapisom dodelite lastna stanja: v teku, poslano, potrjeno, napaka s možnostjo ponovne obdelave, napaka zahteva ukrepanje uporabnika, usklajeno, zaznano neskladje. Dvojiška zastavica „povezano/ni povezano“ vaši podpori ne pove ničesar koristnega.

OAuth in vključevanje povezav

Uporabite tok potrditvene kode (authorization code flow). Stranka klikne gumb Poveži, vaš strežnik ustvari kratkotrajno potrditveno transakcijo, stranka se overi pri ponudniku in dodeli dovoljenja (scopes), kodo zamenjate za žetone, odkrijete pooblaščeno organizacijo, shranite povezavo za ustreznega najemnika in v čakalno vrsto uvrstite začetno usklajevanje.

Skrbno preverite povratni klic: parameter state glede na transakcijo na strežniku, natančen URL za preusmeritev, izdajatelja pri ponudniku in kontekst najemnika. Standard RFC 9700, OAuth 2.0 Security Best Current Practice, formalizira trenutna priporočila: uporabite PKCE s tokovi avtorizacijske kode, izogibajte se implicitnim tokovom in tokovom z geslom ter uporabite natančno ujemanje URL-jev za preusmeritev.

Zahtevajte obsege z najmanjšimi potrebnimi privilegiji (least-privilege scopes). Kjer ni treba pisati podatkov, uporabite samo branje. Modeli obsegov se spreminjajo, zato ne kopirajte starih primerov. Dokumentacija OAuth sistema Xero navaja, da se obsegi s širokimi pooblastili nadčinjajo z bolj podrobnimi, pri čemer so nove aplikacije prejele podrobne obsege od marca 2026, obsegi s širokimi pooblastili pa naj bi ostali na voljo do septembra 2027.

Žetone shranjujte izključno na strežniku. Nikoli jih ne izpostavljajte brskalnikovemu jeziku JavaScript, mobilnim odjemalcem, dnevnikom na čelni strani, analitiki ali sporočilom o napakah za stranke. Šifrirajte v mirovanju, odstranite občutljive podatke iz dnevnikov in hranite metapodatke za posamezno povezavo: šifrirane žetone za dostop in osvežitev, veljavnost, ID organizacije pri ponudniku, odobrena obsega, čas izdaje, zadnjo uspešno osvežitev in stanje preklica.

Rotacija žetonov za osvežitev je točka, kjer produkcija odpove

Odgovor osvežitve lahko vrne nov žeton za osvežitev. Najnovejši vrednost morate shraniti atomarno, sicer boste stranki prekinili dostop. Po navedbah v pogostih vprašanjih za razvijalce Xero vsaka osvežitev ustvari nov žeton za osvežitev, žetoni za osvežitev veljajo do 60 dni, na voljo pa je 30-minutno prehodno obdobje za ponovni poskus z obstoječim žetonom, če se odziv izgubi. QuickBooks Online razvijalcem naroča, naj shranijo najnovejši žeton za osvežitev iz zadnjega odziva: žetoni za osvežitev veljajo do 100 dni, vrednost pa se lahko rotira vsakih 24 ur.

V praksi to pomeni: uporabite zaklepanje osveževanja za posamezno povezavo, atomarno zamenjajte žeton za osvežitev, obravnavajte prehodne napake končne točke za žetone s ponovnimi poskusi, omogočite jasno stanje ponovne avtorizacije in nikoli ne osvežujte ob vsakem klicu API-ja, dokler je veljaven žeton za dostop še na voljo.

Začetno usklajevanje

Začetno usklajevanje zaženite kot ozadnje opravilo (background job). Nanj ne vežite povratnega klica OAuth ali uporabniškega vmesnika.

Zanesljivo zaporedje: pridobite metapodatke organizacije, prejmite konte, davčne stopnje, valute, stike in artikle, shranite ID-je ponudnika in preslikave, uvozite samo tisto zgodovinsko obdobje, ki ga izdelek potrebuje, v čakalno vrsto uvrstite odvisne zapise v vrstnem redu odvisnosti, zabeležite kontrolno točko in povezavo označite kot zdravo šele po preverjanju.

Vrstni red odvisnosti je pomemben. Račun morda zahteva, da najprej obstajajo stik, artikel, prihodkovni konto, davčna koda in valuta. Ne ustvarjajte slepo podvojenih zapisov. Ujemajte jih na podlagi shranjenega zunanjega ID-ja, reference, ki jo je posredovala stranka, določenega pravila ujemanja ali koraka eksplicitne izbire s strani uporabnika v dvoumnih primerih.

Postopno usklajevanje

Spletne kljukice obravnavajte kot signale, ne kot verodostojne zapise

Spletna kljukica običajno sporoča, da se je nekaj spremenilo. Preverite podpis, zabeležite surov dogodek, hitro vrnite zahtevan odziv o uspehu, odstranite podvojene vnose, v čakalno vrsto dodajte nadaljnje pridobivanje, prejmite trenutni predmet od ponudnika, transakcijsko uveljavite posodobitev, posodobite kontrolno točko in napake preusmerite v ponovno obdelavo ali poravnavo. To obravnava nepopolne vsebine in neurejene dogodke.

Pravila ponudnikov se razlikujejo, zato ne obljubljajte enotnega obnašanja. Spletne kljukice Xero vsebujejo podpis HMAC-SHA256 v glavi x-xero-signature, zahtevajo protokol HTTPS, ponavljajo poskuse z manjšo pogostostjo do 24 ur, se lahko po ponovnih napakah onemogočijo in lahko shranjujejo dogodke do 31 dni za ponovno predvajanje po obnovitvi. QuickBooks Online preverja z HMAC-SHA256 in žetonom za preverjanje, pričakuje HTTP 200 v treh sekundah in ponavlja poskuse po določenem urniku, ki se sčasoma ustali v šesturnih intervalih, pri čemer Intuit priporoča asinhrono obdelavo.

Preprečevanje podvajanja in enkratnost (idempotenca)

Dostava vsaj enkrat (at-least-once delivery) je običajna. Pričakujte podvojene spletne kljukice, ponovne poskuse po preteku časa, ko je bilo pisanje dejansko uspešno, preurejene dogodke in ponovne klike uporabnikov. Uporabite ID dogodka ponudnika, če je na voljo, edinstven ključ dogodka v trajnem pomnilniku, operacijski ključ, ustvarjen pred vsakim pisanjem, omejitve enoličnosti v podatkovni bazi, semantiko upsert in poizvedbo za poravnavo po dvoumnih časovnih omejitvah.

Ne predpostavljajte, da vsak računovodski API ponuja izvorne ključe za enkratnost. Če jih ponudnik nima, shranite notranji operacijski ključ in preverite, ali pričakovani oddaljeni predmet že obstaja, preden poskusite znova. Vzorci iz Stripe-ovih enkratnih zahtevkov in splošni napotki za enkratnost spletnih kljukic se tukaj dobro obnesejo.

Anketing (polling) in odkrivanje sprememb

Spletne kljukice povežite s periodičnim anketiranjem. Spletne kljukice se lahko onemogočijo, zakasnijo, izgubijo zaradi napačne nastavitve ali pa so omejene na določene predmete. Xero podpira glavo If-Modified-Since za spremembe po časovnem žigu UTC, vendar njegova dokumentacija opozarja, da vsaka sprememba ne posodobi polja UpdatedDateUTC, zato se nekatere delno plačane transakcije in polja stikov ne bodo prikazale prek tega filtra. Funkcija Change Data Capture v sistemu QuickBooks Online spremlja spremembe zadnjih 30 dni, omejuje odzive na 1.000 predmetov, vrača izbrisane entitete s stanjem Deleted in najbolje deluje s krajšimi okni anketiranja.

Shranite kontrolno točko za posameznega ponudnika in najemnika ter uporabite prekrivajoča se okna. Zahtevajte spremembe od trenutka malo pred zadnjo kontrolno točko, nato pa odstranite dvojnike glede na ID ponudnika in različico spremembe. To ščiti pred časovnim neskladjem (clock skew) in delnimi napakami.

Celovitost računovodskih podatkov

To je del, ki ločuje delujočo integracijo od zaupanja vredne.

Davčno obnašanje ni nadomestljivo. Dokumentacija sistema Xero opozarja, da računi, dobropisi in naročilnice privzeto niso obdavčeni (tax-exclusive), če polje LineAmountTypes ni nastavljeno, potrdila o prejemu in bančne transakcije pa so privzeto z vključenim davkom (tax-inclusive), medtem ko ročni temeljni vknjižbe privzeto nimajo davka. Uporabite polje TaxType, ne imena davčne stopnje. Nikoli ne predpostavljajte, da „20-odstotni DDV“ enolično določa davčno kodo; to se lahko razlikuje glede na državo, vrsto transakcije, datum veljavnosti in nastavitve organizacije. Tu postane večdržavni DDV v EU drag, če ga urejate ročno, in tu si vgrajena glavna knjiga z vgrajeno skladnostjo po državah prisluži svoj pomen.

Za denarne zneske uporabite decimalke ali aritmetiko s fiksno natančnostjo, nikoli plavajoče vejice (floating point). Shranite kodo valute in natančnost, znesek na enoto, količino, popust, znesek davka, neto, bruto in menjalni tečaj. Jasno se odločite, ali boste pošiljali zneske na ravni postavk in prepustili ponudniku izračun vsot ali pa boste poslali vnaprej izračunano vsoto. Mešanje obeh pristopov ustvarja zaokrožitvene neskladnosti, ki jih bo vaš računovodja zagotovo opazil.

Konte v glavni knjigi določajte z ID-jem ali kodo ponudnika, ne z prikazanim imenom. Pred pisanjem preverite, ali so konti, davčne kode, stranke, artikli in valuta aktivni ter podprti. Neuspešno pisanje računa je običajno težava s preslikavo ali nastavitvami in ne prehodna napaka API-ja, zato mora uporabniški vmesnik pojasniti popravek in ne prikazati sporočila „usklajevanje ni uspelo“.

Ne predpostavljajte enakosti predmetov. „Plačilo“ lahko pomeni potrdilo o prejemu, dodelitev, polog, bančno transakcijo ali temeljno vknjižbo. „Naročnina“ v sistemu SaaS se morda ne preslikava čisto na računovodski „račun“. Opredelite računovodski dogodek, ki ga želite prikazati, preden izberete predmet API-ja. Oglejte si dokumentacijo o plačilih sistema Xero za primer, kako en ponudnik modelira te postopke.

Omejitve pogostosti klicev (rate limits) in različice

Omejitve so običajno določene na ravni najemnika, organizacije, aplikacije ali njihove kombinacije. Po pogostih vprašanjih o omejitvah za Xero: pet sočasnih zahtevkov na najemnika, 60 na minuto na najemnika, 5.000 na dan na najemnika in 10.000 na minuto v celotni aplikaciji, skupaj z glavami preostalih omejitev in Retry-After ob napakah 429. QuickBooks Online določa 500 zahtevkov na minuto in 10 na sekundo na ID področja, pri čemer končna točka za paketno obdelavo podpira do 30 operacij na zahtevek.

Zgradite omejevanje pogostosti na ravni najemnika, globalno dušenje (throttling), eksponentno ponavljanje z naključnim zakasnjevanjem (jitter), spoštovanje glave Retry-After, omejeno sočasnost, paginacijo in meritve za napake 429 ter preostalo kvoto. Za uvoze ne uporabljajte neomejene vzporednosti; ena velika stranka lahko izčrpa vsako drugo opravilo pri tem najemniku.

Pripnite ali izrecno upravljajte različice API-ja. QuickBooks Online privzeto uporablja manjšo različico 75, če nobena ni določena. Različice centralizirajte v nastavitvah, izvedite pogodbeno testiranje na preskusnih okoljih (sandboxes), spremljajte opombe ob izdaji in neznana odzivna polja obravnavajte kot združljiva za nazaj in naprej. Preskusna okolja ne bodo poustvarila vsakega produkcijskega pogoja, zato pred zagonom preizkusite prekinitev povezave, ponovno povezavo, preklicano privolitev, pretečene žetone, omejitve pogostosti in urejanja na strani ponudnika.

Kaj bi zgradil najprej

Če bi jutri začel znova, bi sledil temu vrstnemu redu:

Opredelite natančen računovodski delovni tok: katere dogodke in predmete berete ali pišete.
Izberite strategijo ponudnika: neposredna, poenotena, vgrajena ali hibridna.
Zgradite model povezave, vezan na najemnika, z ID-ji organizacije pri ponudniku, obsegi, stanjem in metapodatki žetonov.
Izvedite OAuth s tokom avtorizacijske kode, PKCE, preverjanjem stanja, obsegi z najmanjšimi privilegiji in shranjevanjem žetonov na strežniku.
Zgradite enega prilagojevalnika ponudnika za stabilnim notranjim vmesnikom.
Ustvarite preslikave ID-jev na nespremenljivih ID-jih ponudnika.
Najprej izvedite bralne operacije; pred kakršnim koli pisanjem uvozite referenčne podatke.
Dodajte posel začetnega usklajevanja s paginacijo, omejevanjem pogostosti, kontrolnimi točkami in urejanjem odvisnosti.
Izvedite eno ožjo pisno operacijo (ustvarjanje računa) šele, ko so preslikave strank, artiklov, davkov in kontov preverjene.
Napišite funkcije za varno ponavljanje z notranjimi ID-ji operacij, omejitvami enoličnosti in preverjanji oddaljenega stanja.
Dodajte podpisane spletne kljukice, ki se hitro odzovejo in se obdelujejo asinhrono.
Dodajte anketiranje in poravnavo, tako da so spletne kljukice pospeševalnik, ne pa edini vir resnice.
Skrbno preizkusite načine odpovedi.
Dodajte orodja za podporo in revizijo, ki napake naredijo razumljive in popravljive.
Postopoma razširite pokritost predmetov.

FAQ

Naj uporabim poenoten API ali zgradim neposredne povezovalnike?

Neposredni povezovalnik uporabite, ko en ponudnik prevladuje med vašimi strankami ali je obnašanje, specifično zanj, ključnega pomena. Poenoten API preučite, ko sta široka pokritost in hitrost pomembnejši od nadzora. Če je vaša resnična potreba vodenje lastnih knjig in ne usklajevanje s strankinim sistemom, nobeden od njiju ne ponuja odgovora; raje si oglejte vgrajeno glavno knjigo, kot je Nordlet.

Ali so spletne kljukice dovolj za vzdrževanje usklajenosti?

Ne. Spletne kljukice so lahko onemogočene, zapoznele ali izgubljene, vsebine pa so lahko nepopolne ali neurejene. Obravnavajte jih kot signale sprememb, nato pridobite trenutni predmet ter jih podprite s periodičnim anketiranjem in poravnavo.

Kako preprečim, da bi napake žetonov za osvežitev prekinile dostop strankam?

Najnovejši žeton za osvežitev shranite atomarno ob vsaki osvežitvi, uporabite zaklepanje za posamezno povezavo, ponovite poskuse ob prehodnih napakah končne točke za žetone in omogočite jasno stanje ponovne avtorizacije. 30-minutno prehodno obdobje sistema Xero pomaga, vendar je atomarno shranjevanje tisto, kar vas reši.

Ali lahko ujemam zapise po imenu ali e-pošti stranke?

Ne kot trajni identifikator. Imena se spreminjajo, pojavljajo se dvojniki, dve stranki pa si lahko delita e-poštni naslov. Shranite nespremenljiv ID ponudnika in poleg njega ohranite svoj ID v SaaS.