Kako integrirati API za računovodstvo u oblaku u SaaS platformu

Vodič za praktičare o izgradnji višestanskične (multi-tenant) računovodstvene integracije koja funkcionira uz OAuth, webhookove, porezna pravila i usklađivanje bez narušavanja glavne knjige.

Većina timova koji odluče "dodati računovodstvo" u svoj SaaS proizvod započinje povezivanjem HTTP klijenta s krajnjom točkom pružatelja usluge i slanjem računa. To funkcionira u demo verziji. Puca onog trenutka kada korisnik poveže dvije računovodstvene organizacije, kada webhook stigne dvaput te kada se token za osvježavanje (refresh token) rotira i izgubi usred zahtjeva. Dugotrajna i pouzdana verzija ovog posla nije klijent, već integracijski sloj.

Taj sloj mora upravljati vezama zakupaca (tenants), pohranom i rotacijom tokena, računovodstvenim pravilima specifičnima za pružatelja usluge, mapiranjem zapisa, inicijalnom i inkrementalnom sinkronizacijom, prihvaćanjem webhookova s ponovnim pokušajima i uklanjanjem duplikata, ograničenjima učestalosti (rate limits), upravljanjem verzijama te revizijskim tragom (audit trail) koji vaš tim za podršku može pročitati u 2 sata ujutro. Ovaj članak prolazi kroz tu arhitekturu i odluke koje su najvažnije.

Korisan mentalni model:

SaaS proizvod → integracijski servis za računovodstvo → adapter pružatelja usluge (ili jedinstveni API) → asinkrona sinkronizacija i usklađivanje

Računovodstveni sustav ostaje izvor istine za stavke glavne knjige: konta, porezne kodove, proknjižene transakcije i temeljnice. Vaša SaaS platforma zadržava stabilne identifikatore između sustava, stanje sinkronizacije, metapodatke mapiranja i operativni revizijski zapis.

Što "API za računovodstvo u oblaku" ovdje zapravo obuhvaća

Izraz obično označava API platforme za knjigovodstvo u oblaku kao što su QuickBooks Online, Xero, Sage, Zoho Books ili neki regionalni sustav. Također može značiti jedinstveni računovodstveni API koji normalizira nekoliko pružatelja usluga iza jednog sučelja.

Vrijedi biti precizan jer se implementacija razlikuje ovisno o namjeri. Čitanje računa za izvještavanje nije isti posao kao stvaranje računa iz SaaS aktivnosti, knjiženje ulaznih računa, sinkronizacija kupaca i proizvoda, pisanje temeljnica ili pokretanje prave dvosmjerne sinkronizacije. Odlučite što od toga gradite prije nego što dotaknete bilo koju krajnju točku.

Još jedna distinkcija važna je za ovaj članak. API za plaćanje premješta novac. Bankovni API povlači podatke o računu. API za fakturiranje može stvarati dokumente bez izlaganja glavne knjige. Ugrađena računovodstvena glavna knjiga nešto je sasvim drugo: SaaS tvrtka posjeduje sam računovodstveni mehanizam. Taj posljednji pristup jest ono gdje se nalazi Nordlet. Umjesto povezivanja vašeg proizvoda s vanjskim knjigama vašeg kupca, Nordlet platformama i marketplace (tržištima) pruža pravu dvostvarnu knjiogu, nepromjenjivu glavnu knjigu spremnu za reviziju, obradu EU PDV-a i isplate unutar vlastitog proizvoda, putem dizajna usmjerenog na API s tipiziranim SDK-ovima i webhookovima. Ako ste marketplace koji odlučuje hoće li integrirati korisnikov računovodstveni sustav ili samostalno voditi knjige, to je pravo raskrižje i na to ćemo se vratiti.

Višestanačnost (Multi-tenancy): dvaput obuhvatite svaku vezu

U SaaS proizvodu jedna aplikacija se povezuje s mnogo korisničkih organizacija. Svaka veza mora biti obuhvaćena i SaaS zakupcem i identifikatorom organizacije pružatelja usluge, kao što su Xero ID zakupca (tenant ID) ili QuickBooks ID područja (realm ID).

Nemojte temeljiti veze samo na OAuth korisničkom ID-ju. Jedan korisnik može ovlastiti nekoliko računovodstvenih organizacija, a jednu organizaciju tijekom vremena mogu ponovno povezati različiti korisnici. Ako ovo pogriješite, prije ili kasnije ćete račun jednog kupca proknjižiti u knjige drugog kupca, a to nije pogreška od koje se tiho oporavljate.

Prva arhitektonska odluka: izravni konektor, jedinstveni API ili ugrađena glavna knjiga

Izravne integracije s pružateljem usluge

Izravna integracija pruža vam najveću kontrolu: značajke specifične za pružatelja usluge, prilagođena polja, obradu pogrešaka, učestalost sinkronizacije, zadržavanje podataka i strukturu troškova. Cijena je stvarna. Svaki pružatelj donosi vlastiti OAuth tijek, shemu, osobitosti, ograničenja učestalosti, ponašanje webhookova, certifikaciju i tekuće održavanje.

Jedinstveni računovodstveni API-ji

Jedinstveni API nudi jedno sučelje za nekoliko računovodstvenih sustava, normalizirajući entitete poput kupaca, računa, dobavljača, konta, plaćanja i proizvoda. Može skratiti početno vrijeme izrade. Ipak, ne uklanja složenost integracije, a postupanje s njim kao da to čini uobičajena je pogreška.

Prije nego što se obvežete, pitajte: Koji su pružatelji usluga i operacije podržani? Rade li upisi (writes) ili samo čitanja? Jesu li upisi sinkroni ili u redu čekanja? jesu li polja specifična za pružatelja dostupna putem prolaza (passthrough)? Jesu li podaci predmemorirani i koliko su svježi? Tko rješava prekide rada pružatelja usluge i promjene API-ja? Je li cijena po pozivu, po povezanom računu, po zapisu ili naknada za platformu? Možete li izvesti svoja mapiranja i čisto se odspojiti? "Jedinstveno" rijetko znači "funkcionalno ekvivalentno kod svih pružatelja".

Ugrađena glavna knjiga

Ako je temeljni problem vaše platforme vođenje računovodstva za vaše korisnike, a ne njegovo odražavanje u njihovim postojećim knjigama, ugrađena glavna knjiga mijenja računicu. Marketplace s tisućama prodavača ili SaaS proizvod koji u sebi mora imati ugrađen EU PDV spreman za reviziju i usklađenost po državama, bolje će proći ako posjeduje računovodstveni mehanizam nego spajanjem N vanjskih konektora. To je Nordletovo pozicioniranje: prave knjige kao API, nepromjenjivo dvostruko knjigovodstvo, PDV po državama s VIES provjerom i generiranjem i.SAF registra, SEPA izvoz i izvoz izvješća u XLSX, PDF ili JSON formatu, sve unutar vašeg proizvoda umjesto naplate treće strane.

Pravilo odluke koje koristim:

Situacija	Najbolje odgovara
Jedan računovodstveni pružatelj dominira vašom korisničkom bazom; ponašanje specifično za pružatelja je ključno	Izravni konektor
Široka pokrivenost pružatelja i brzina izlaska na tržište važniji su od kontrole	Jedinstveni API
Vi ste platforma ili marketplace koja treba voditi i posjedovati knjige, uz EU PDV i revizijske tragove	Ugrađena glavna knjiga (Nordlet)
Miješana stvarnost	Hibridno: jedinstveno za uobičajene tokove, izravni konektori za strateške pružatelje

Preporučena arhitektura integracije

Izolirajte integraciju od temeljne poslovne logike

Nemojte razbacivati pozive prema pružatelju usluga kroz naplatu, narudžbe, pretplate i izvještavanje. Izgradite namjenski integracijski servis koji sadrži adaptere pružatelja usluga, upravljanje OAuth vezama, kanonske modele, mapiranja ID-jeva, poslove i redove čekanja za sinkronizaciju, webhook krajnje točke, obradu ponovnih pokušaja i mrtvih redova (dead-letter), revizijske zapise i alate za usklađivanje. Time se sprječava da naziv polja iz Xera ili QuickBooksa procuri u vaš domenski model.

Definirajte uži kanonski model

Modelirajte samo radne procese koje podržavate. Tipični objekti: kupac, proizvod ili stavka usluge, račun, stavka računa, plaćanje, odobrenje (credit note), dobavljač, konto, porezna stopa, valuta, temeljnica.

Zadržite razlike koje utječu na računovodstvo. Nemojte sravniti nacrt (draft) u odnosu na odobreno u odnosu na proknjiženo, iznose s uključenim porezom u odnosu na iznose bez poreza, odobrenja u odnosu na negativne račune, alokaciju plaćanja u odnosu na postojanje plaćanja, ili broj računa vidljiv kupcu u odnosu na ID objekta pružatelja usluge. Svaki zapis treba nositi SaaS ID, ID pružatelja usluge, naziv pružatelja usluge i verziju API-ja, pokazatelj izvora istine, status, vremenske oznake, vrijeme posljednje sinkronizacije, vanjsku referencu i status pogreške/usklađivanja.

Održavajte eksplicitne tablice mapiranja

Mapirajte SaaS zakupca na računovodstvenu organizaciju, SaaS kupca na kontakt kod pružatelja usluge, SaaS proizvod na stavku ili konto pružatelja usluge, SaaS račun na račun pružatelja usluge, SaaS plaćanje na plaćanje pružatelja usluge, poreznu kategoriju na porezni kod te kategoriju prihoda na konto glavne knjige.

Nikada nemojte koristiti nazive ili adrese e-pošte kao trajne identifikatore. Nazivi se mijenjaju, postoje duplikati, a dva kupca mogu dijeliti istu adresu e-pošte. Pohranite nepromjenjivi ID pružatelja usluge i zadržite izvorni SaaS ID.

Dodajte strojeve stanja (state machines)

Dodajte vezi eksplicitna stanja: nije povezano, odobrenje na čekanju, povezano, inicijalna sinkronizacija na čekanju, sinkronizacija u tijeku, zdravo, ograničeno prema učestalosti (rate limited), potrebno ponovno odobrenje, pružatelj nedostupan, odspojeno, trajno neuspjelo. Dodajte zapisima njihova vlastita stanja: na čekanju, poslano, potvrđeno, neuspjelo s mogućnošću ponovnog pokušaja, neuspjelo – zahtijeva radnju korisnika, usklađeno, otkriven sukob. Binarna oznaka "povezano/nije povezano" vašem timu za podršku ne govori ništa korisno.

OAuth i uvođenje u vezu (onboarding)

Koristite tijek s kodom ovlaštenja (authorization code flow). Kupac klikne Poveži se, vaš poslužitelj stvara kratkotrajnu transakciju ovlaštenja, kupac se autentificira kod pružatelja usluge i dodjeljuje opsege (scopes), vi mijenjate kod za tokene, otkrivate ovlaštenu organizaciju, pohranjujete vezu uz ispravnog zakupca i stavljate u red čekanja inicijalnu sinkronizaciju.

Pažljivo provjerite povratni poziv (callback): state u odnosu na transakciju na strani poslužitelja, točan URI preusmjeravanja, izdavatelja pružatelja usluge i kontekst zakupca. RFC 9700, OAuth 2.0 Security Best Current Practice, formalizira trenutne smjernice: koristite PKCE s tijekovima koda ovlaštenja, izbjegavajte implicitne i lozinkovne dodjele te koristite točno podudaranje URI-ja preusmjeravanja.

Zatražite opsege s najmanjim potrebnim ovlastima (least-privilege scopes). Koristite čitanje (read-only) tamo gdje ne trebate pisati. Modeli opsega se mijenjaju, stoga nemojte kopirati stare primjere. Xerova OAuth dokumentacija napominje da se široki računovodstveni opsezi zamjenjuju granularnima, pri čemu su nove aplikacije dobile granularne opsege od ožujka 2026., a široki opsezi ostaju dostupni do rujna 2027.

Pohranite tokene isključivo na strani poslužitelja. Nikada ih nemojte izlagati JavaScriptu u pregledniku, mobilnim klijentima, zapisnicima sučelja (frontend logs), analitici ili porukama o pogreškama vidljivim kupcima. Šifrirajte u mirovanju, uklonite osjetljive podatke iz zapisnika i čuvajte metapodatke po vezi: šifrirane pristupne tokene i tokene za osvježavanje, rok valjanosti, ID organizacije pružatelja, dodijeljene opsege, vrijeme izdavanja, posljednje uspješno osvježavanje i status opoziva.

Rotacija tokena za osvježavanje je mjesto gdje produkcija puca

Odgovor osvježavanja može vratiti novi token za osvježavanje. Najnoviju vrijednost morate atomski pohraniti, inače ćete zaključati korisnika. Prema Xerovom razvojnom FAQ-u, svako osvježavanje proizvodi novi token za osvježavanje, tokeni za osvježavanje traju do 60 dana, a postoji poček od 30 minuta za ponovni pokušaj s postojećim tokenom ako se odgovor izgubi. QuickBooks Online poručuje razvojnim inženjerima da pohrane najnoviji token za osvježavanje iz najnovijeg odgovora: tokeni za osvježavanje traju do 100 dana, a vrijednost se može rotirati čak svaka 24 sata.

U praksi: koristite zaključavanje osvježavanja po vezi, atomski zamijenite token za osvježavanje, tretirajte prolazne pogreške krajnje točke tokena s ponovnim pokušajima, izložite jasno stanje ponovnog odobrenja i nikada nemojte osvježavati pri svakom API pozivu dok valjani pristupni token još postoji.

Inicijalna sinkronizacija

Pokrenite inicijalnu sinkronizaciju kao pozadinski posao. Nemojte blokirati OAuth povratni poziv ili korisničko sučelje njome.

Robusni slijed: dohvatite metapodatke organizacije, preuzmite konta, porezne stope, valute, kontakte i stavke, pohranite ID-jeve pružatelja usluge i mapiranja, uvezite samo povijesni prozor koji proizvod treba, stavite zavisne zapise u red čekanja prema redoslijedu zavisnosti, zabilježite kontrolnu točku (checkpoint) i označite vezu zdravom tek nakon provjere valjanosti.

Redoslijed zavisnosti je važan. Račun možda zahtijeva da kontakt, stavka, konto prihoda, porezni kod i valuta već postoje. Nemojte naslijepo stvarati duplikate. Uskladite podatke prema pohranjenom vanjskom ID-ju, referenci koju je dostavio kupac, definiranom pravilu usklađivanja ili koraku eksplicitnog odabira od strane korisnika za dvosmislene slučajeve.

Inkrementalna sinkronizacija

Tretirajte webhookove kao signale, ne kao mjerodavne zapise

Webhook obično javlja da se nešto promijenilo. Provjerite potpis, zabilježite sirovi događaj, brzo vratite traženi uspješan odgovor, uklonite duplikate, stavite u red čekanja naknadni dohvat, preuzmite trenutni objekt od pružatelja usluge, primijenite ažuriranje transakcijski, ažurirajte kontrolnu točku i usmjerite neuspjehe na ponovni pokušaj ili usklađivanje. Time se rješavaju nepotpuni korisni tereti (payloads) i događaji izvan redoslijeda.

Pravila pružatelja usluga se razlikuju, stoga nemojte obećavati jedno univerzalno ponašanje. Xerovi webhookovi nose HMAC-SHA256 potpis u zaglavlju x-xero-signature, zahtijevaju HTTPS, ponavljaju pokušaje sa smanjenom učestalošću do 24 sata, mogu se onemogućiti nakon opetovanih neuspjeha i mogu spremati događaje do 31 dan radi ponovne reprodukcije nakon oporavka. QuickBooks Online vrši provjeru s HMAC-SHA256 i tokenom za provjeru, očekuje HTTP 200 unutar tri sekunde i ponavlja pokušaje po fiksnom rasporedu koji se s vremenom pretvara u intervale od šest sati, pri čemu Intuit preporučuje asinkronu obradu.

Uklanjanje duplikata i idempotentnost

Isporuka barem jednom (at-least-once) je uobičajena. Očekujte dvostruke webhookove, ponovne pokušaje nakon isteka vremena kada je upis zapravo uspio, preuređene događaje i dvostruke klikove korisnika. Koristite ID događaja pružatelja usluge gdje je dostupan, jedinstveni ključ događaja u trajnoj pohrani, ID operacije generiran prije svakog upisa, ograničenja jedinstvenosti baze podataka, semantiku umetni-ili-ažuriraj (upsert) i upit za usklađivanje nakon dvosmislenih isteka vremena.

Nemojte pretpostavljati da svaki računovodstveni API nudi izvorne ključeve idempotentnosti. Ako pružatelj usluge to ne čini, pohranite interni ključ operacije i provjerite postoji li već očekivani udaljeni objekt prije ponovnog pokušaja. Obrasci iz Stripeovih idempotentnih zahtjeva i općih smjernica za idempotentnost webhookova ovdje se izvrsno prenose.

Polling i otkrivanje promjena

Uparite webhookove s povremenim anketiranjem (polling). Webhookovi se mogu onemogućiti, odgoditi, izgubiti zbog pogrešne konfiguracije ili biti ograničeni na određene objekte. Xero podržava zaglavlje If-Modified-Since za promjene nakon UTC vremenske oznake, ali njegova dokumentacija upozorava da svaka promjena ne ažurira UpdatedDateUTC, tako da se neke djelomično plaćene transakcije i polja kontakata neće pojaviti putem tog filtra. QuickBooks Online Change Data Capture prati promjene iz prethodnih 30 dana, ograničava odgovore na 1.000 objekata, vraća izbrisane entitete sa statusom Deleted i najbolje funkcionira s kraćim prozorima anketiranja.

Pohranite kontrolnu točku po pružatelju i po zakupcu te koristite prozore preklapanja. Zatražite promjene od trenutka neposredno prije posljednje kontrolne točke, a zatim uklonite duplikate prema ID-ju pružatelja usluge i verziji izmjene. Time se postiže zaštita od vremenskog pomaka (clock skew) i djelomičnih neuspjeha.

Računovodstveni integritet podataka

Ovo je dio koji odvaja radnu integraciju od pouzdane.

Porezno ponašanje nije zamjenjivo. Xerova dokumentacija napominje da računi, odobrenja i narudžbenice zadano koriste iznose bez poreza kada LineAmountTypes nije postavljen, potvrde i bankovne transakcije zadano koriste iznose s uključenim porezom, a ručne temeljnice zadano nemaju porez. Koristite polje TaxType, a ne naziv porezne stope. Nikada nemojte pretpostavljati da "20% PDV-a" jedinstveno identificira porezni kod; on se može razlikovati ovisno o državi, vrsti transakcije, datumu stupanja na snagu i konfiguraciji organizacije. Ovdje EU višekratni PDV po državama postaje skup za ručno ispravljanje i ovdje ugrađena glavna knjiga s ugrađenom usklađenošću po državama zaslužuje svoje mjesto.

Koristite decimalnu aritmetiku ili aritmetiku fiksnog zareza za novac, nikada binarni s pomičnim zarezom (floating point). Trajno zapišite oznaku valute i preciznost, jedinični iznos, količinu, popust, iznos poreza, neto, bruto i tečaj. Jasno odlučite šaljete li iznose na razini stavke i dopuštate li pružatelju da izračuna ukupne iznose, ili šaljete unaprijed izračunati ukupni iznos. Miješanje ta dva pristupa stvara odstupanja u zaokruživanju koja će vaš računovođa pronaći.

Upućujte na konta glavne knjige putem ID-ja pružatelja usluge ili koda, a ne naziva za prikaz. Prije upisa provjerite jesu li konta, porezni kodovi, kupci, stavke i valuta aktivni i podržani. Neuspjeli upis računa obično je problem mapiranja ili konfiguracije, a ne prolazna API pogreška, stoga korisničko sučelje treba objasniti popravak umjesto da prikazuje "sinkronizacija nije uspjela".

Nemojte pretpostavljati ekvivalenciju objekata. "Plaćanje" može značiti primitak, alokaciju, depozit, bankovnu transakciju ili temeljnicu. SaaS "pretplata" možda se neće uredno preslikati na računovodstveni "račun". Definirajte računovodstveni događaj koji želite predstaviti prije nego što odaberete API objekt. Pogledajte Xerovu dokumentaciju o plaćanjima za prikaz kako jedan pružatelj usluge to modelira.

Ograničenja učestalosti i verzije

Ograničenja su obično obuhvaćena po zakupcu, organizaciji, aplikaciji ili njihovoj kombinaciji. Prema Xerovom FAQ-u o ograničenjima: pet istovremenih zahtjeva po zakupcu, 60 u minuti po zakupcu, 5.000 dnevno po zakupcu i 10.000 u minuti na razini cijele aplikacije, uz zaglavlja preostalog ograničenja i Retry-After kod kodova 429. QuickBooks Online dokumentira 500 zahtjeva u minuti i 10 u sekundi po ID-ju područja (realm ID), uz skupnu krajnju točku (batch endpoint) koja podržava do 30 operacija po zahtjevu.

Izgradite ograničavanje učestalosti po zakupcu, globalno prigušivanje (throttling), eksponencijalno usporavanje s nasumičnim odmakom (exponential backoff with jitter), poštivanje zaglavlja Retry-After, ograničenu istovremenost, paginaciju i metrike o kodovima 429 i preostaloj kvoti. Nemojte koristiti neograničenu paralelnost za uvoze; jedan veliki kupac može izgladnjeti svaki drugi posao na tom zakupcu.

Fiksirajte ili eksplicitno upravljajte verzijama API-ja. QuickBooks Online zadano koristi sporednu verziju 75 kada nijedna nije navedena. Centralizirajte verzije u konfiguraciji, pokrenite testove ugovora protiv okruženja u sandboxu, pratite napomene uz izdanja i tretirajte nepoznata polja odgovora kao kompatibilna sa sljedećim verzijama (forward-compatible). Sandbox okruženja neće reproducirati svako produkcijsko stanje, stoga prije lansiranja testirajte odspajanje, ponovno povezivanje, opozvani pristanak, istekle tokene, ograničenja učestalosti i uređivanja na strani pružatelja usluge.

Što bih prvo izgradio

Kad bih ovo započinjao sutra, redoslijed bi bio:

Definirati točan računovodstveni tijek rada: koje događaje i objekte čitate ili pišete.
Odabrati strategiju pružatelja usluge: izravna, jedinstvena, ugrađena ili hibridna.
Izgraditi model veze obuhvaćen zakupcem s ID-jevima organizacije pružatelja, opsezima, statusom i metapodatcima tokena.
Implementirati OAuth s tijekovima koda ovlaštenja, PKCE-om, provjerom stanja, opsezima s najmanjim potrebnim ovlastima i pohranom tokena na strani poslužitelja.
Izgraditi jedan adapter pružatelja usluge iza stabilnog internog sučelja.
Stvoriti mapiranja ID-jeva na nepromjenjivim ID-jevima pružatelja usluge.
Prvo implementirati čitanja; uvesti referentne podatke prije bilo kakvog upisa.
Dodati posao inicijalne sinkronizacije s paginacijom, ograničenjem učestalosti, kontrolnim točkama i redoslijedom zavisnosti.
Implementirati jedno uže pisanje (stvaranje računa) tek nakon što se provjere mapiranja kupca, stavke, poreza i konta.
Učiniti upise otpornima na ponovne pokušaje pomoću internih ID-jeva operacija, ograničenja jedinstvenosti i provjera udaljenog stanja.
Dodati potpisane webhookove koji brzo potvrđuju primitak i obrađuju se asinkrono.
Dodati anketiranje (polling) i usklađivanje tako da webhookovi budu ubrzanje, a ne jedini izvor istine.
Namjerno testirati načine neuspjeha.
Dodati alate za podršku i reviziju koji neuspjehe čine razumljivima i popravljivima.
Postupno proširiti pokrivenost objektima.

FAQ

Trebam li koristiti jedinstveni API ili graditi izravne konektore?

Koristite izravni konektor kada jedan pružatelj usluga dominira vašim kupcima ili je ponašanje specifično za pružatelja ključno. Razmislite o jedinstvenom API-ju kada su široka pokrivenost i brzina važniji od kontrole. Ako je vaša stvarna potreba samostalno vođenje knjiga umjesto sinkronizacije s korisničkim sustavom, nijedan odgovor ne rješava pitanje; umjesto toga pogledajte ugrađenu glavnu knjigu poput Nordleta.

Jesu li webhookovi dovoljni za ostanak u sinkronizaciji?

Ne. Webhookovi se mogu onemogućiti, odgoditi ili izgubiti, a korisni tereti mogu biti nepotpuni ili izvan redoslijeda. Tretirajte ih kao signale promjene, nakon toga dohvatite trenutni objekt i podržite ih povremenim anketiranjem i usklađivanjem.

Kako spriječiti da neuspjesi tokena za osvježavanje zaključaju korisnike?

Atomski pohranite najnoviji token za osvježavanje pri svakom osvježavanju, koristite zaključavanje po vezi, ponovite prolazne neuspjehe krajnje točke tokena i izložite jasno stanje ponovnog odobrenja. Xerov poček od 30 minuta pomaže, ali atomsko spremanje je ono što vas spašava.

Mogu li uskladiti zapise prema imenu kupca ili adresi e-pošte?

Ne kao trajni identifikator. Imena se mijenjaju, događaju se duplikati, a dva kupca mogu dijeliti istu adresu e-pošte. Pohranite nepromjenjivi ID pružatelja usluge i uz njega zadržite vlastiti SaaS ID.