Šta je API integracija i kako funkcioniše.

API integracija je veza koja omogućava da dva softverska sistema automatski razmjenjuju podatke. API (application programming interface, programski interfejs aplikacije) je skup zahtjeva koje sistem prima od drugog softvera, na primjer "kreiraj ovu fakturu" ili "pošalji mi današnje plaćene narudžbe". Integracija šalje te zahtjeve, pa plaćena narudžba iz web shopa postane izlazna faktura, a da je niko ne prepisuje.

Kada dobavljač kaže da njegov proizvod "ima API", to znači da je integracija moguća. Neko je i dalje mora izraditi. Kada kaže da se "integriše s" vašim računovodstvenim programom ili ERP-om, pitajte koji zapisi se prenose, u kojem smjeru, koliko često i ko dobija obavještenje kada zapis ne prođe. Jednosmjerno noćno kopiranje novih kupaca i dvosmjerna sinhronizacija narudžbi računaju se kao integracije, a posla oko njih je vrlo različito.

Ako je integracija jedan korak u većem procesu koji želite automatizovati, naš vodič o automatizaciji poslovanja objašnjava kako prvo izabrati taj proces.

Svaka razmjena preko API-ja je zahtjev nakon kojeg slijedi odgovor. Jedan sistem šalje zahtjev na adresu koju drugi sistem objavljuje, a koja se zove endpoint, uz token koji dokazuje ko pita. Sistem koji prima zahtjev provjerava token, izvršava zahtjev i odgovara podacima, potvrdom ili kodom greške.

Evo jedne razmjene između dva ilustrativna sistema, web shopa i računovodstvenog programa u cloudu:

1. 01Kupac plati narudžbu 10482. Web shop odmah šalje integraciji kratku poruku da je narudžba plaćena. Ovako poslana poruka zove se webhook.
2. 02Integracija od API-ja web shopa traži cijelu narudžbu: kupca, stavke narudžbe, PDV i dostavu.
3. 03Prevodi narudžbu u pojmove računovodstvenog programa: šifru proizvoda u šifru artikla, stopu PDV-a u PDV oznaku i e-mail adresu kupca u odgovarajućeg kupca iz šifarnika.
4. 04Od računovodstvenog API-ja traži kreiranje izlazne fakture i uz zahtjev šalje svoj pristupni token.
5. 05Računovodstveni program provjerava token i podatke, kreira fakturu i odgovara kodom uspjeha i brojem fakture.
6. 06Integracija sačuva broj fakture uz narudžbu i bilježi razmjenu, uspješnu ili neuspješnu.

Koraci 4 i 5 izgledaju otprilike ovako u JSON formatu preko HTTPS-a, koji koristi većina modernih API-ja. Adresa, polja i vrijednosti izmišljeni su za ovaj primjer.

POST https://accounting.example.com/api/v1/sales-invoices
Authorization: Bearer <access-token>
Content-Type: application/json
Idempotency-Key: webshop-order-10482

{
  "customer_id": "C-2291",
  "invoice_date": "2026-09-15",
  "reference": "webshop-order-10482",
  "lines": [
    { "item_code": "MUG-BLUE", "quantity": 2, "unit_price": 12.50, "vat_code": "HIGH" }
  ]
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "invoice_number": "2026-00731",
  "status": "open"
}

201 Created znači da je uspjelo. Greške koriste druge kodove, kao što su 401 za pogrešan token, 400 ili 422 za polje koje ne prođe validaciju i 429 za previše zahtjeva. Zaglavlje Idempotency-Key govori API-ju koji to podržava da zanemari ponovljeni isti zahtjev, pa ponovni pokušaj ne može kreirati drugu fakturu za narudžbu 10482.

Suprotnost webhooku je polling: integracija u fiksnim razmacima pita da li se nešto promijenilo. Stariji sistemi često dozvoljavaju samo polling, a neki imaju samo izvoz datoteka ili bazu podataka, bez ikakvog API-ja. Njihovo povezivanje je posao integracije starijih sistema.

Većina integracija u finansijama i operativi prenosi jednu vrstu zapisa iz sistema u kojem nastaje u sistem kojem sljedećem treba: narudžbu, fakturu, kupca ili rezervaciju. Tri tipična slučaja pokazuju šta se prenosi i gdje je teži dio posla.

Od web shopa do računovodstva

Plaćene narudžbe postaju izlazne fakture, povrati postaju knjižna odobrenja, a isplate pružaoca usluga plaćanja uparuju se s njima. Platforme za online prodaju kao što su Shopify i WooCommerce, i računovodstveni programi kao što je Exact Online, objavljuju dokumentovane API-je za ovakav tok.

Teži dio je novac koji se ne poklapa jedan na jedan. Pružalac usluga plaćanja često isplaćuje jednom dnevno za mnogo narudžbi, umanjeno za svoje naknade, pa se jedna bankovna transakcija mora upariti s desetinama faktura i knjiženjem naknade. PDV za kupce u drugim zemljama EU i razlike zbog zaokruživanja drugi su uobičajeni izvori izuzetaka.

Od CRM-a do ERP-a

Kada se prodajna prilika u CRM-u zatvori kao dobijena, kupac i narudžba idu u ERP, da operativa može isporučiti, a finansije fakturisati. Status plaćanja se vraća, pa account manager vidi da li je kupac platio. CRM sistemi kao što su HubSpot i Salesforce, i ERP sistemi kao što je AFAS Profit, javno dokumentuju svoje API-je.

Oba sistema drže podatke o kupcima, pa je prva odluka koji sistem je vlasnik kojeg polja. Adresa za dostavu i uslovi plaćanja mogu pripadati ERP-u, a kontakt osoba i bilješke o prodajnoj prilici CRM-u. Bez tog pravila izmjena u jednom sistemu prepiše ispravku napravljenu u drugom. Duplikati su drugi čest problem: ista firma unesena dva puta pod malo drugačijim nazivima.

Od portala za klijente do planiranja

Kupac u portalu rezerviše termin za dostavu ili servisnu posjetu. Portal pita sistem za planiranje koji su termini slobodni, rezerviše jedan i pokazuje potvrdu. Kada planer pomjeri termin, promjena se vraća u portal.

Teži dio je vrijeme. Dva kupca mogu istovremeno pokušati rezervisati posljednji termin, pa sistem za planiranje mora rezervisati i potvrditi u jednom koraku, a portal treba jasnu poruku kada je termin upravo zauzet.

U sva tri slučaja poziv API-ja je manji dio posla. Zato naši projekti integracije sistema počinju mapiranjem koji sistem je vlasnik kojeg polja, prije nego što se išta poveže.

Integraciju možete dobiti na tri načina: uključiti standardni konektor koji nudi jedan od dobavljača, izraditi tok na platformi za integraciju kao što su n8n, Make ili Zapier, ili naručiti kod za integraciju pisan za vaše sisteme. Šta odgovara, odlučuju obim, koliko je tok važan, koliko je mapiranje neobično i ko će ga održavati.

Ako standardni konektor postoji i pokriva vaš proces, počnite od njega; mnogim integracijama nikad ne treba više. Prvo ga testirajte na nezgodnim slučajevima, kao što su knjižna odobrenja i djelimične isporuke. Na platformama za integraciju radimo gdje odgovaraju, a kod po mjeri pišemo gdje to traže obim ili logika, kako opisuje naša stranica o API integracijama.

Većina grešaka u integracijama prođe tiho. Zapis nikad ne stigne, stigne dva puta ili stigne s praznim poljem, a niko to ne primijeti do zatvaranja mjeseca ili žalbe kupca. Za svaku postoji poznata zaštita, a onoga ko izrađuje ili prodaje integraciju možete pitati koje su zaštite uključene.

Ograničenja broja poziva

API-ji ograničavaju koliko zahtjeva klijent smije poslati u minuti ili danu. Obrada na kraju mjeseca ili veliki uvoz mogu doći do tog ograničenja, a API tada odgovara 429 Too Many Requests, često sa zaglavljem koje kaže kada pokušati ponovo. Velike poslove rasporedite u vremenu, koristite endpointe za masovnu obradu gdje postoje, čekajte koliko API traži i preostale zapise stavite u red, da nijedan ne ispadne.

Promijenjena polja i verzije API-ja

Dobavljač preimenuje polje, neobavezno polje učini obaveznim ili ukine staru verziju API-ja. Ili neko u vašoj organizaciji doda PDV oznaku u jednom sistemu, a u drugom ne. Integracija i dalje radi, ali zapisi završavaju u pogrešnom polju ili ih sistem počne odbijati.

Gdje postoji verzionisan API, izrađujte na njemu i pratite obavještenja dobavljača o ukidanju. Svaki zapis provjerite prema obliku koji integracija očekuje, a svaki zapis koji ne odgovara izdvojite, s razlogom. Kada dobavljač najavi promjenu, testirajte je u sandboxu (testnoj kopiji sistema) prije nego što stigne do stvarnih podataka.

Tihe greške

One koštaju najviše, jer ih ništa ne prijavljuje. Webhook se izgubi jer strana koja ga prima nekoliko minuta nije radila. Pristupni token istekne, a noćna sinhronizacija stane bez ijedne zabilježene greške. API vrati kod uspjeha, a unutar odgovora stoji poruka o grešci.

Pratite i izostanak aktivnosti, uz greške: ako se tokom radnog vremena dva sata nije sinhronizovala nijedna narudžba, neko to treba saznati. Uz statusni kod čitajte i tijelo odgovora, pošaljite upozorenje prije isteka pristupnih podataka i povremeno provjerite sve što se promijenilo od posljednjeg pokretanja, da se propušteni webhookovi pokupe.

Ponovni pokušaji

Privremene greške, kao što su istek vremena ili kratak prekid rada, vrijedi ponoviti: integracija sama pokušava ponovo, nakon svakog pokušaja čeka duže i staje nakon određenog broja pokušaja. Trajne greške, kao što je nepoznata PDV oznaka, ne prolaze koliko god puta ih poslali. Takvi zapisi idu u red gdje čovjek vidi zapis i grešku, ispravi uzrok i ponovo ga pošalje.

Duplikati i idempotentnost

Ponovni pokušaji nose vlastiti rizik. Računovodstveni sistem kreira fakturu, odgovor istekne na putu nazad, integracija pokuša ponovo i kupac dobije dvije fakture. Webhookovi prave isti problem, jer mnoge platforme svaki događaj isporučuju barem jednom, što ponekad znači dva puta.

Zaštita je idempotentnost: isti zahtjev poslan dva puta ima isti efekat kao da je poslan jednom. Koristite idempotency ključ gdje ga API podržava, prije kreiranja novog zapisa provjerite postoji li zapis s istom referencom i bilježite koji su događaji već obrađeni.

Upozorenja koja stignu do čovjeka

Upozorenje u zajedničkom sandučiću koji niko ne čita ništa ne rješava. Svaku grešku pošaljite imenovanom vlasniku, sa zapisom, greškom i načinom da se zapis ponovo pošalje. Odbijena faktura ide finansijama; veza koja ne radi ide onome ko održava integraciju. Ponovljene greške grupišite, da jedan prekid pošalje jedno upozorenje.

Usklađivanje

Usklađivanje je posljednja zaštita, a finansijski timovi tu naviku znaju iz usklađivanja bankovnih izvoda s glavnom knjigom. Redovni izvještaj poredi oba sistema: na primjer, broj i ukupnu vrijednost jučerašnjih plaćenih narudžbi iz web shopa s izlaznim fakturama kreiranim u računovodstvu tog dana, uz spisak svake razlike. Otkriva i ručne izmjene napravljene samo u jednom sistemu.

Prije nego što prihvatite integraciju, od dobavljača ili vlastitog tima, pitajte:

• Šta se dešava sa zapisom koji drugi sistem odbije, i ko dobija obavještenje?
• Ako isti događaj stigne dva puta, može li nastati druga faktura ili narudžba?
• Kako bismo saznali da se cijeli dan ništa nije sinhronizovalo?
• Koji sistem ima prednost kada se isto polje promijeni u oba?
• Postoji li izvještaj o usklađivanju, i ko ga čita?
• Kada dobavljač promijeni API, ko to primijeti i ko popravlja integraciju?

Trošak API integracije najviše određuje ono što okružuje samu vezu: koliko je sistema i vrsta zapisa uključeno, koliko su dobri njihovi API-ji, idu li podaci u jednom ili oba smjera, koliko izuzetaka proces ima i koliko praćenja tok traži. Pitajte kako ponuda uzima u obzir svaku od tih stavki.

• Sistemi i vrste zapisa. Kupci, narudžbe, fakture i knjižna odobrenja trebaju svako svoje mapiranje i pravila.
• Kvalitet API-ja. Jasna dokumentacija, sandbox i webhookovi ubrzavaju posao; polja koja nedostaju ili nedokumentovan API ga usporavaju.
• Smjer. Dvosmjerna sinhronizacija traži pravila o vlasništvu za svako polje i rješavanje konflikata.
• Izuzeci, kao što su djelimične isporuke, strani PDV i spojeni kupci, od kojih svaki treba definisan put.
• Historijski podaci koje treba upariti ili migrirati prije nego što sinhronizacija počne raditi na stvarnim podacima.
• Praćenje i podrška nakon puštanja u rad, uključujući alate za ponovno slanje i izvještaje o usklađivanju.
• Licence: naknade za konektore, korištenje platforme i naknade koje neki dobavljači naplaćuju za pristup API-ju ili veća ograničenja broja poziva.

U računicu uključite i trošak rada, uz trošak izrade, jer se sistemi na oba kraja stalno mijenjaju. Obim i trošak dogovaramo u pisanom planu nakon analize, kada su sistemi, podaci i izuzeci mapirani.

Možemo li sami napraviti API integraciju?

Često možete, za jednostavne slučajeve. Ako standardni konektor ili platforma za integraciju povezuje dva alata u širokoj upotrebi, obim je mali, a pogrešan zapis se lako uoči i ispravi, sposobna osoba u vašem timu može je postaviti i biti zadužena za nju. Dodajte provjere iz dijela o greškama, jer ih platforme uglavnom prepuštaju vama.

Naručite izradu kada integracija u velikom obimu kreira fakture, plaćanja ili zapise o kupcima, sinhronizuje podatke u oba smjera, uključuje stariji sistem ili mora izdržati reviziju.

Da li je API integracija sigurna?

Može biti, zavisno od toga kako je postavljena. Pristupne podatke čuvajte u alatu za tajne podatke (secrets manager) i nikad ih ne stavljajte u tabele ili e-mailove. Svakoj integraciji dajte samo pristup koji joj treba: ključ koji kreira fakture nema razloga čitati podatke o platama. Podatke šaljite preko šifrovanih veza i provjeravajte potpis na dolaznim webhookovima, da niko ne može slati lažne događaje.

Lične podatke ograničite na ono što treba sistemu koji ih prima i ne upisujte ih u logove. Ukinite ključeve kada zaposlenik ili dobavljač ode, i imajte ugovor o obradi podataka sa svakim ko održava integraciju koja prenosi lične podatke.

Koja je razlika između webhooka i pollinga?

Kod webhooka izvorni sistem šalje poruku u trenutku kada se nešto desi. Kod pollinga integracija u određenim razmacima pita da li se nešto promijenilo. Webhookovi su brži i manje opterećuju sisteme, ali poruka se može izgubiti, pa pouzdane integracije često koriste webhookove zbog brzine i povremeni polling da uhvate sve što je propušteno.