Kuidas integreerida pilveraamatupidamise API SaaS-platvormi

Enamik tiime, kes võtavad vastu otsuse lisada oma SaaS-tootele "raamatupidamisfunktsioon", alustavad HTTP-kliendi ühendamisest teenusepakkuja otspunktiga ja arve saatmisest. Demo tasemel see töötab. See läheb katki esimesel korral, kui klient ühendab kaks raamatupidamisorganisatsiooni, esimesel korral, kui veebikonks (webhook) saabub topelt, ja esimesel korral, kui värskendustõend (refresh token) uueneb ja päringu keskel kaotsi läheb. Sellise töö vastupidav versioon ei ole pelgalt klient, vaid integratsioonikiht.

See kiht peab haldama rentnike ühendusi, tõendite hoiustamist ja vahetust, teenusepakkujapõhiseid raamatupidamisreegleid, kirjete vastendamist, esmast ja inkrementaalset sünkroonimist, veebikonksude vastuvõtmist koos korduskatsete ja dublikaatide eemaldamisega, päringupiiranguid, versioonihaldust ning auditijälge, mida teie klienditugi suudab lugeda ka kell 2 öösel. Käesolev artiklites käsitleb seda arhitektuuri ja otsuseid, millel on suurim kaal.

Kasulik vaimne mudel:

SaaS-toode → raamatupidamisintegratsiooni teenus → teenusepakkuja adapter (või ühtne API) → asünkroonne sünkroonimine ja vastavusse viimine

Raamatupidamissüsteem jääb pearaamatu objektide tõeallikaks (system of record): kontod, maksekoodid, postitatud tehingud, pearaamatu kanded. Teie SaaS-platvorm säilitab süsteemiülesed stabiilsed identifikaatorid, sünkroonimise oleku, vastendusmetadandad ja operatiivse audtilogi.

Mida "pilveraamatupidamise API" siinkohal tegelikult hõlmab

See väljend tähendab tavaliselt majutatud raamatupidamisplatvormi (näiteks QuickBooks Online, Xero, Sage, Zoho Books või mõni piirkondlik süsteem) API-d. See võib tähendada ka ühtset (unified) raamatupidamise API-d, mis normaliseerib mitu teenusepakkujat ühe liidese taha.

Sellesse tasub suhtuda täpselt, kuna teostus erineb sõltuvalt eesmärgist. Aruandluse jaoks arvete lugemine ei ole sama töö mis arvete loomine SaaS-i tegevuse põhjal, ostuarvete sisestamine, klientide ja toodete sünkroonimine, pearaamatu kannete tegemine või tõelise kahesuunalise sünkroonimise käitamine. Otsustage ära, mida täpselt ehitate, enne kui puudutate ühtegi otspunkti.

Selle artikli jaoks on oluline veel üks eristus. Maksete API liigutab raha. Pangandus-API tõmbab kontode andmeid. Arvelduse API saab luua dokumente ilma pearaamatut paljastamata. Sisseehitatud (embedded) raamatupidamise pearaamat on aga hoopis midagi muud: SaaS-ettevõte omab raamatupidamismootorit ennast. Just viimane lähenemine on see, kus Nordlet asub. Selle asemel, et ühendada teie toode kliendi väliste raamatupidamisandmetega, annab Nordlet platvormidele ja turgudele (marketplaces) päris kahekordse kirje raamatupidamise, muutmiskindla auditivalmi pearaamatu, EL-i käibemaksuhalduse ja väljamaksed otse nende enda toote sees, kasutades API-keskset disaini koos tüübistatud SDK-de ja veebikonksudega. Kui olete turg, mis otsustab, kas integreerida kliendi raamatupidamissüsteem või pidada raamatupidamist ise, on tegemist tõelise ristteega ja me tuleme selle juurde veel tagasi.

Mitmikrentlus (multi-tenancy): seadke igale ühendusele topeltpiirangud

SaaS-tootes ühendub üks rakendus paljude kliendiorganisatsioonidega. Iga ühendus peab olema piiritletud nii SaaS-i rentniku (tenant) kui ka teenusepakkuja organisatsiooni identifikaatoriga, näiteks Xero rentniku ID või QuickBooks realm-ID.

Ärge siduge ühendusi ainuüksi OAuth-i kasutaja ID-ga. Üks kasutaja võib volitada mitut raamatupidamisorganisatsiooni ja ühte organisatsiooni võivad aja jooksul uuesti ühendada erinevad kasutajad. Kui teete siin vea, postitate ühel hetkel ühe kliendi arve teise kliendi raamatupidamisse ja sellest veast ei taastuta vaikselt.

Esimene arhitektuuriline otsus: otseadapter, ühtne API või sisseehitatud pearaamat

Otseühendused teenusepakkujatega

Otseintegratsioon annab teile suurima kontrolli: teenusepakkujapõhised funktsioonid, kohandatud väljad, veatöötlus, sünkroonimissagedus, andmete säilitamine ja kulustruktuur. Hind on aga reaalne. Iga teenusepakkuja toob kaasa oma OAuth-voo, skeemi, eripärad, päringupiirangud, veebikonksude käitumise, sertifitseerimise ja jooksva hoolduse.

Ühtsed raamatupidamise API-d (unified APIs)

Ühtne API pakub ühte liidest mitme raamatupidamissüsteemi jaoks, normaliseerides sellised olemid nagu kliendid, arved, tarnijad, kontod, maksed ja tooted. See võib lühendada esmast ehitusaega. See ei kõrvalda aga integratsiooni keerukust ja selle eelpokstamine on levinud viga.

Enne otsuse tegemist küsige: millised teenusepakkujad ja toimingud on toetatud? Kas kirjutamine töötab või ainult lugemine? Kas kirjutamised on sünkroonsed või järjekorras? Kas teenusepakkujapõhised väljad on kättesaadavad otselÄbivoolu (passthrough) kaudu? Kas andmed on vahemällu salvestatud ja kui värsked need on? Kes tegeleb teenusepakkuja katkestuste ja API muudatustega? Kas hinna aluseks on päring, seotud kontode arv, kirjete arv või platvormitasu? Kas saate oma vastendused eksportida ja puhtalt lahutada? "Ühtne" tähendab harva "funktsionaalselt võrdne kõigi teenusepakkujate puhul".

Sisseehitatud pearaamat (embedded ledger)

Kui teie platvormi põhiprobleem on kasutajate eest raamatupidamise pidamine, mitte selle peegeldamine nende olemasolevatesse raamatutesse, muudab sisseehitatud pearaamat arvutuskäiku. Turupaik, kus on tuhandeid müüjaid, või SaaS-toode, mis vajab sisseehitatud auditivalmis EL-i käibemaksu ja riigipõhist vastavust, saab parema tulemuse raamatupidamismootori omamisest, mitte N välise konnektori ühendamisest. See on Nordleti positsioneering: päris raamatupidamine API kaudu, muutumatu kahekordne kirje, riigipõhine käibemaks VIES-kontrolli ja i.SAF-i registri genereerimisega, SEPA eksport ning aruannete eksport XLSX-, PDF- või JSON-formaadis otse teie tootes, mitte kolmanda osapoole kassas.

Otsusreegel, mida kasutan:

Olukord	Parim valik
Üks raamatupidamisteenuse pakkuja domineerib teie kliendibaasi üle; pakkujaomane käitumine on kesksel kohal	Otseadapter
Lai teenusepakkujate katvus ja turule jõudmise kiirus on olulisemad kui kontroll	Ühtne API
Olete platvorm või turg, mis peab raamatupidamist ise omama ja käitama, koos EL-i käibemaksu ja auditijälgedega	Sisseehitatud pearaamat (Nordlet)
Segarealsus	Hübriid: ühtne API levinud voogude jaoks, otseadapterid strateegiliste teenusepakkujate jaoks

Soovitatud integratsiooniarhitektuur

Isoleerige integratsioon põhiäri loogikast

Ärge pillutage teenusepakkuja päringuid arvelduse, tellimuste, tellimuslepingute (subscriptions) ja aruandluse vahel. Ehitage spetsiaalne integratsiooniteenus, mis sisaldab teenusepakkuja adaptereid, OAuthi ühenduste haldust, kanoonilisi mudeleid, ID vastendusi, sünkroonimistöid ja -järjekordi, veebikonksude otspunkte, korduskatsete ja nurjunud sõnumite (dead-letter) haldust, audtiloge ning vastavusse viimise tööriistu. See hoiab ära Xero või QuickBooks-i väljanimede lekkimise teie domeenimudelisse.

Määratlege kitsas kanooniline mudel

Modelleerige ainult neid töövooge, mida toetate. Tüüpilised objektid: klient, toode või teenus, arve, arverida, makse, kreeditarve, tarnija, konto, maksumäär, valuuta, pearaamatu kanne.

Säilitage eristused, mis mõjutavad raamatupidamist. Ärge tasandage mustandit kinnitatud või postitatud olekuks, käibemaksuga summasid käibemaksuta summadest, kreeditarveid negatiivsetest arvetest, makse jaotust makse olemasolust ega kliendile suunatud arvenumbrit teenusepakkuja objekti ID-st. Iga kirje peab kandma SaaS-i ID-d, teenusepakkuja ID-d, teenusepakkuja nime ja API versiooni, tõeallika indikaatorit, olekut, ajatempleid, viimast sünkroonimisaega, välist viidet ja vea/vastavuse olekut.

Säilitage selged vastendustabelid

Vastendage SaaS-i rentnik raamatupidamisorganisatsiooniga, SaaS-i klient teenusepakkuja kontaktiga, SaaS-i toode teenusepakkuja kauba või kontoga, SaaS-i arve teenusepakkuja arvega, SaaS-i makse teenusepakkuja maksekirjega, maksukategooria maksekoodiga ja tulukategooria pearaamatu kontoga.

Ärge kunagi kasutage alaliste identifikaatoritena nimesid ega e-posti aadresse. Nimed muutuvad, esineb duplikaate, kaks klienti võivad jagada ühte e-posti aadressi. Salvestage teenusepakkuja muutumatu ID ja säilitage algne SaaS-i ID.

Lisage olekumasinad (state machines)

Andke ühendusele selged olekud: ühendamata, autoriseerimine ootel, ühendatud, esmane sünkroonimine ootel, sünkroonimine käib, terve, päringupiiranguga seotud, taasautoriseerimine vajalik, teenusepakkuja kättesaamatu, ühendus katkestatud, püsivalt ebaõnnestunud. Andke kirjetele nende oma olekud: ootel, saadetud, kinnitatud, ebaõnnestunud-korduvkatsetatav, ebaõnnestunud-vajab-kasutaja-tegevust, vastavusse viidud, tuvastatud konflikt. Binaarne ühendatud/ühendamata lipp ei ütle teie klienditoele midagi kasulikku.

OAuth ja ühenduse loomine

Kasutage autoriseerimiskoodi voogu (authorization code flow). Klient klõpsab nupul "Ühenda", teie server loob lühiealise autoriseerimistehingu, klient autentib end teenusepakkuja juures ja annab õigused (scopes), te vahetate koodi tõendite vastu, tuvastate volitatud organisatsiooni, salvestate ühenduse õige rentniku külge ja panete järjekorda esmase sünkroonimise.

Valideerige tagasikutset hoolikalt: parameetrit state serveripoolse tehingu suhtes, täpset ümbersuunamise URI-d (redirect URI), teenusepakkuja väljastajat ja rentniku konteksti. RFC 9700, OAuth 2.0 Security Best Current Practice formaliseerib kehtivad soovitused: kasutage autoriseerimiskoodi voogudes PKCE-d, vältige implitsiitseid (implicit) ja paroolipõhiseid õiguste jagamisi ning kasutage täpset ümbersuunamise URI-de vastavust.

Taotlege minimaalseid õigusi (least-privilege scopes). Kasutage lugemisõigust seal, kus kirjutada pole vaja. Õiguste mudelid muutuvad, nii et ärge kopeerige vanu näiteid. Xero OAuth dokumentatsioon märgib, et laiad raamatupidamisõigused asendatakse peenematega; uutele rakendustele määrati peened õigused alates 2026. aasta märtsist ja laiad õigused jäävad kättesaadavaks kuni 2027. aasta septembrini.

Hoiustage tõendeid ainult serveri poolel. Ärge kunagi avaldage neid brauseri JavaScriptis, mobiiliklientides, esiotsa logides, analüütikas ega kliendile suunatud veateadetes. Krüpteerige andmebaasis, eemaldage logidest ja säilitage ühendusepõhiseid metandmeid: krüpteeritud juurdepääsu- ja värskendustõendid (access and refresh tokens), aegumistähtaeg, teenusepakkuja organisatsiooni ID, antud õigused, väljastusaeg, viimane edukas värskendamine, tühistamise olek.

Tõendite värskendamise pööramine (refresh-token rotation) on koht, kus toodang katki läheb

Värskendamispäring võib tagastada uue värskendustõendi. Peate uusima väärtuse aatomiliselt (atomically) salvestama, vastasel juhul lukustate kliendi välja. Xero arendaja KKK kohaselt toodab iga värskendamine uue värskendustõendi, värskendustõendid kehtivad kuni 60 päeva ja vastuse kadumisel on olemas 30-minutiline armuaeg olemasoleva tõendiga uuesti proovimiseks. QuickBooks Online soovitab arendajatel salvestada värskeima vastuse viimase värskendustõendi: värskendustõendid kehtivad kuni 100 päeva ja väärtus võib vahetuda nii tihti kui iga 24 tunni järel.

Praktikas: kasutage ühendusepõhist värskenduse lukustust, asendage värskendustõend aatomiliselt, käsitlege tõrgete korral transiitseid tõendite otspunkti tõrkeid korduskatsetega, kuvage selge taasautoriseerimise olek ja ärge kunagi tehke värskendamist igal API päringul, kui kehtiv juurdepääsutõend on endiselt olemas.

Esmane sünkroonimine

Käivitage esmane sünkroonimine taustatööna. Ärge blokeerige selle tõttu OAuthi tagasikutset ega kasutajaliidest.

Vastupidav järjekord: hankige organisatsiooni metainfo, laadige kontod, maksumäärad, valuutad, kontaktid ja kaubad, salvestage teenusepakkuja ID-d ja vastendused, importige ainult toote jaoks vajalik ajalooline aken, pange sõltuvad kirjed sõltuvusjärjekorras järjekorda, salvestage kontrollpunkt (checkpoint) ja märkige ühendus terveks alles pärast valideerimist.

Sõltuvusjärjekord on oluline. Arve võib vajada seda, et kontakt, kaup, tulukonto, maksekood ja valuuta on juba olemas. Ärge looge pimesi duplikaate. Sobitage salvestatud välise ID, kliendi esitatud viite, määratletud sobitusreegli või mitmetähenduslike juhtumite puhul selge kasutaja valiku alusel.

Inkrementaalne sünkroonimine

Käsitlege veebikonksusid signaalidena, mitte autoriteetsete kirjetena

Veebikonks ütleb tavaliselt, et midagi on muutunud. Kontrollige allkirja, salvestage toorsündmus, tagastage nõutud edukuse vastus kiiresti, eemaldage dublikaadid, pange järelpäring järjekorda, hankige teenusepakkujalt praegune objekt, rakendage uuendustehing, uuendage kontrollpunkti ja suunake tõrked korduskatsele või vastavusse viimisele. See lahendab mittetäielikud andmepaketid ja sündmuste vale järjekorra.

Teenusepakkuja reeglid on erinevad, nii et ärge lubage ühte universaalset käitumist. Xero veebikonksud kannavad HMAC-SHA256 allkirja päises x-xero-signature, nõuavad HTTPS-i, kordavad katseid kahaneva sagedusega kuni 24 tundi, võivad korduvate tõrgete järel deaktiveeruda ja säilitavad sündmusi taastumise järgseks taasesituseks kuni 31 päeva. QuickBooks Online verifitseerib HMAC-SHA256 ja verifitseerimistõendi abil, ootab HTTP 200 vastust kolme sekundi jooksul ja kordab katseid fikseeritud graafiku alusel, mis lõpuks stabiliseerub kuuetunnisteks intervallideks, kusjuures Intuit soovitab asünkroonset töötlemist.

Dublikaatide eemaldamine ja identsustagamine (idempotency)

Vähemalt ühekordne kohaletoimetamine (at-least-once delivery) on normaalne. Oodake topeltveebikonksusid, ajalõpu järgseid korduskatseid, kus kirjutamine tegelikult õnnestus, ümberpaigutatud sündmusi ja topeltklõpsamisi. Kasutage teenusepakkuja sündmuse ID-d, kui see on saadaval, unikaalset sündmuse võtit püsivas salvestuses, enne iga kirjutamist genereeritud toimingu ID-d, andmebaasi unikaalsuspiiranguid, upsert-semantikat ja vastavusse viimise päringut pärast ebamääraseid ajalõppe.

Ärge eeldage, et iga raamatupidamise API pakub natiivseid identsustagamise võtmeid. Kui teenusepakkuja seda ei tee, salvestage sisemine toimingu võti ja kontrollige enne korduskatset, kas oodatud kaugobjekt on juba olemas. Stripe'i identsustagamise mustrid (idempotent requests) ja üldine veebikonksude identsustagamise juhend kanduvad siia hästi üle.

Pärimine (polling) ja muudatuste tuvastamine

Siduge veebikonksud perioodilise pärimisega. Veebikonksud võidakse keelata, viivitada, valest konfigureerimisest tingituna kaotada või piirata teatud objektidega. Xero toetab päist If-Modified-Since muudatuste jaoks pärast UTC ajatemplit, kuid selle dokumentatsioon hoiatab, et mitte iga muudatus ei uuenda välja UpdatedDateUTC, mistõttu mõned osaliselt tasutud tehingud ja kontaktide väljad ei ilmu selle filtri kaudu. QuickBooks Online'i muudatusandmete hõive (Change Data Capture) jälgib muudatusi eelneva 30 päeva jooksul, piirab vastused 1,000 objektiga, tagastab kustutatud olemid olekuga Deleted ja töötab kõige paremini lühemate pärimisakendega.

Salvestage teenusepakkuja- ja rentnikupõhine kontrollpunkt ning kasutage kattuvaid aknaid. Taotlege muudatusi veidi enne viimast kontrollpunkti, seejärel eemaldage dublikaadid teenusepakkuja ID ja muudatusversiooni järgi. See kaitseb süsteemikella nihete ja osaliste tõrgete eest.

Raamatupidamispõhine andmete terviklikkus

See on osa, mis eristab töötava integratsiooni usaldusväärsest.

Maksuarvutus ei ole asendatav. Xero dokumentatsioon märgib, et arved, kreeditarved ja ostutellimused on vaikimisi ilma käibemaksuta (tax-exclusive), kui LineAmountTypes on määramata, kviitungid ja pangatehingud on vaikimisi käibemaksuga (tax-inclusive) ning käsitsi tehtud kanded on vaikimisi ilma maksudeta. Kasutage välja TaxType, mitte maksumäära nime. Ärge kunagi eeldage, et "20% käibemaks" tuvastab üheselt maksekoodi; see võib erineda riigiti, tehingutüübi, kehtivusaja ja organisatsiooni seadistuse järgi. Siin muutub EL-i mitme riigi käibemaks käsitsi tehes kulukaks ja siin teenib oma koha riigipõhise vastavusega sisseehitatud pearaamat.

Kasutage raha jaoks kümnend- või fikseeritud täpsusega aritmeetikat, mitte kunagi binaarset ujukomaarvu (floating point). Säilitage valuutakood ja täpsus, ühiku summa, kogus, allahindlus, maksu summa, netosumma, brutosumma ja vahetuskurss. Otsustage selgelt, kas saadate reataseme summad ja lasete teenusepakkujal kogusummad arvutada, või saadate eelnevalt arvutatud kogusumma. Nende kahe segamine tekitab ümarduslahknevusi, mille teie raamatupidaja üles leiab.

Viidake pearaamatu kontodele teenusepakkuja ID või koodi, mitte kuvatava nime järgi. Enne kirjutamist valideerige, et kontod, maksekoodid, kliendid, kaubad ja valuuta on aktiivsed ja toetatud. Ebaõnnestunud arve kirjutamine on tavaliselt vastenduse või konfiguratsiooni probleem, mitte transiitne API tõrge, nii et kasutajaliides peaks vea näitamise asemel selgitama parandust.

Ärge eeldage objektide samaväärsust. "Makse" võib tähendada kviitungit, jaotust, deposiiti, pangatehingut või pearaamatu kannet. SaaS-i "tellimus" ei pruugi raamatupidamise "arvega" puhtalt vastenduda. Määrake raamatupidamissündmus, mida soovite esitada, enne kui valite API objekti. Vaadake Xero maksete dokumentatsiooni näitena sellest, kuidas üks teenusepakkuja seda ahendab.

Päringupiirangud (rate limits) ja versioonihaldus

Piirangud on tavaliselt seotud rentniku, organisatsiooni, rakenduse või nende kombinatsiooniga. Xero piirangute KKK kohaselt: viis samaaegset päringut rentniku kohta, 60 minutis rentniku kohta, 5,000 päevas rentniku kohta ja 10,000 minutis kogu rakenduse peale, koos järelejäänud limiidi päiste ja koodiga 429 tagastatava Retry-After päisega. QuickBooks Online dokumenteerib 500 päringut minutis ja 10 sekundis realm-ID kohta, pakett-otspunktiga (batch endpoint), mis toetab kuni 30 toimingut päringu kohta.

Ehitage rentnikupõhine päringute piiramine, globaalne piiramine (throttling), eksponentsiaalne tagasipöördumine (exponential backoff) koos juhusliku nihkega, Retry-After austamine, piiratud samaaegsus, lehekülgedeks jaotamine ning mõõdikud 429 vastuste ja vaba kvoodi kohta. Ärge kasutage impordiks piiramatut paralleelsust; üks suur klient võib näljutada iga teise töö sellel rentnikul.

Kinnitage või hallake selgelt API versioone. QuickBooks Online kasutab vaikimisi alamversiooni 75, kui seda pole määratud. Keskendage versioonid konfiguratsioonis, käivitage liidesetestid (contract tests) liivakastides (sandboxes), jälgige väljalaskemärkmeid ja käsitlege tundmatuid vastuse välju edasiühilduvatena. Liivakastid ei reprodutseeri kõiki toodangu tingimusi, nii et katsetage enne turuletoomist lahtiühendamist, uuesti ühendamist, tühistatud nõusolekut, aegunud tõendeid, päringupiiranguid ja teenusepoolseid muudatusi.

Mida ma ehitaks esimesena

Kui alustaksin seda homme, siis järgmises järjekorras:

1. Mõelge välja täpne raamatupidamistöövoog: milliseid sündmusi ja objekte loete või kirjutate.
2. Valige teenusepakkuja strateegia: otseadapter, ühtne API, sisseehitatud või hübriid.
3. Ehitage rentnikupõhine ühenduse mudel koos teenusepakkuja organisatsiooni ID-de, õiguste, oleku ja tõendi metainfoga.
4. Rakendage OAuth autoriseerimiskoodi voo, PKCE, oleku valideerimise, minimaalsete õiguste ja serveripoolse tõendite salvestamisega.
5. Ehitage stabiilse sisemise liidese taha üks teenusepakkuja adapter.
6. Looge ID vastendused teenusepakkuja muutumatute ID-de alusel.
7. Rakendage esmalt lugemine; importige viiteandmed enne kirjutamist.
8. Lisage esmane sünkroonimistöö lehekülgedeks jaotamise, päringupiirangute, kontrollpunktide ja sõltuvusjärjekorraga.
9. Rakendage üks kitsas kirjutustoiming (arve loomine) alles pärast seda, kui kliendi, kauba, maksu ja kontode vastendused on valideeritud.
10. Tehke kirjutamised korduskatsekindlaks sisemiste toimingu ID-de, unikaalsuspiirangute ja kaugoleku kontrollidega.
11. Lisage allkirjastatud veebikonksud, mis annavad kiire vastuse ja töötlevad asünkroonselt.
12. Lisage pärimine ja vastavusse viimine, et veebikonksud oleksid kiirenduseks, mitte ainsaks tõeallikaks.
13. Katsetage teadlikult rikkeolukordi.
14. Lisage tugi- ja audititööriistad, mis teevad tõrked selgitatavaks ja parandatavaks.
15. Laiendage objektide katvust järk-järgult.

FAQ

Kas ma peaks kasutama ühtset API-d või ehitama otseadapterid?

Kasutage otseadapterit siis, kui üks teenusepakkuja domineerib teie klientide seas või pakkujaomane käitumine on keskse tähtsusega. Kaaluge ühtset API-d siis, kui lai katvus ja kiirus on olulisemad kui kontroll. Kui teie tegelik vajadus on pidada raamatupidamist ise, selle asemel et sünkroonida kliendi süsteemiga, ei vasta neist kumbki küsimusele; vaadake selle asemel sisseehitatud pearaamatut nagu Nordlet.

Kas veebikonksudest piisab sünkroonis püsimiseks?

Ei piisa. Veebikonksud võidakse keelata, edasi lükata või kaotada ning andmepaketid võivad olla mittetäielikud või vales järjekorras. Käsitlege neid muudatussignaalidena, hankige seejärel praegune objekt ning toetage neid perioodilise pärimise ja vastavusse viimisega.

Kuidas hoida ära värskendustõendi tõrgete kliendi väljalukustamist?

Salvestage uusim värskendustõend aatomiliselt iga värskenduse käigus, kasutage ühendusepõhist lukustust, katsetage transiitseid tõendi otspunkti tõrkeid uuesti ja kuvage selge taasautoriseerimise olek. Xero 30-minutiline armuaeg aitab, kuid aatomiline salvestamine on see, mis teid päästab.

Kas ma saan kirjeid sobitada kliendi nime või e-posti aadressi järgi?

Mitte alalise identifikaatorina. Nimed muutuvad, esineb duplikaate ja kaks klienti võivad jagada ühte e-posti aadressi. Salvestage teenusepakkuja muutumatu ID ja säilitage selle kõrval omaenda SaaS-i ID.

Edasine lugemine

• Xero OAuth 2.0 ülevaade
• Xero API piirangud
• Stripe identsustagamise päringud
• Nordleti API dokumentatsioon