Kako smo povezali webshop, ERP, CRM i mobilnu aplikaciju u jedinstven, bezbedan i skalabilan API ekosistem

Sažetak projekta

Klijent je distributivna kompanija koja prodaje robu kroz više kanala: B2B webshop, terensku prodaju, call centar i direktnu obradu porudžbina u ERP-u. Glavni problem nije bio nedostatak softvera, već to što postojeći sistemi nisu radili kao celina. Porudžbine su se duplirale, stanje lagera kasnilo, CRM nije imao ažurne podatke, a timovi su previše vremena trošili na ručne provere i prepisivanje podataka.

Zadatak je bio da se razvije centralni REST API sloj koji će povezati sve ključne poslovne sisteme, standardizovati razmenu podataka i postaviti bezbednu osnovu za dalju automatizaciju. Rešenje je projektovano prema savremenim principima dokumentovanja HTTP API-ja kroz OpenAPI, uz oslonac na zero-trust pristup i preporuke za zaštitu API komunikacije, kao i na prioritete iz OWASP API Security Top 10.

Profil klijenta

Klijent je srednje velika distributivna firma sa sledećim digitalnim okruženjem:

• B2B webshop za naručivanje robe
• ERP sistem za fakturisanje, lager i logistiku
• CRM za evidenciju kupaca i komercijalnih aktivnosti
• mobilna aplikacija za terenske komercijaliste
• centralna baza proizvoda, cena i partnera

Pre razvoja API servisa, svaki kanal je radio parcijalno. Podaci su se unosili više puta, a ključne informacije nisu bile dostupne u realnom vremenu.

Poslovni izazov

Klijent se suočavao sa nekoliko kritičnih operativnih problema:

• webshop prikazuje stanje lagera koje nije uvek ažurno
• porudžbine se ručno prenose u ERP ili dodatno proveravaju
• CRM ne vidi odmah nove kupce, limite i status realizacije
• mobilni komercijalisti nemaju pouzdan uvid u cene, stanja i istoriju kupovine
• partneri često zovu ili šalju upite za informacije koje bi sistem mogao automatski da pruži

Posledice su bile usporeno poslovanje, više administracije, veći rizik od grešaka i lošije korisničko iskustvo.

Cilj projekta

Cilj nije bio samo “napraviti API”, već izgraditi centralni integracioni servis koji će:

• sinhronizovati porudžbine između webshopa i ERP-a
• omogućiti pouzdanu proveru zaliha i cena u realnom vremenu
• standardizovati pristup kupcima, proizvodima i statusima narudžbina
• obezbediti siguran pristup za različite tipove klijenata i sistema
• olakšati buduće integracije sa mobilnim aplikacijama i partner portalima
• smanjiti operativni trošak i ručni rad

Predloženo rešenje

Projektovali smo REST API platformu kao centralni sloj između svih sistema. API je postavljen kao jedini kontrolisani ulaz/izlaz za razmenu poslovnih podataka.

Ključne funkcionalne celine

• autentifikacija i autorizacija korisnika i sistema
• katalog proizvoda i cenovnici
• pregled stanja lagera po magacinima
• kreiranje i sinhronizacija porudžbina
• statusi obrade, isporuke i naplate
• partneri, kupci, limiti i komercijalni podaci
• logovanje svih kritičnih API poziva
• dokumentacija za interne i eksterne integracije

Arhitektura rešenja

Ovakav pristup omogućava da se pravila poslovanja, bezbednost i validacija drže na jednom mestu, umesto da budu rasuti po više aplikacija.

Tok obrade porudžbine

Kako je API organizovan

API je organizovan po verzijama, resursima i ulogama pristupa.

Primeri ključnih endpointa:

• POST /api/v1/auth/token
• GET /api/v1/products
• GET /api/v1/inventory/{sku}
• POST /api/v1/orders
• GET /api/v1/orders/{id}
• PATCH /api/v1/orders/{id}/status
• GET /api/v1/customers/{id}/limits

Verzionisanje API-ja preko /v1/ olakšava buduće izmene bez rušenja postojećih integracija. Standardizovana dokumentacija je pripremljena kroz OpenAPI specifikaciju, a OpenAPI Initiative trenutno objavljuje zvanične specifikacije i HTML prikaze standarda, pri čemu je OAS 3.2.0 objavljen u septembru 2025. godine.

Tehnološki pristup

Za ovakav tip projekta preporučen je stack koji daje dobar balans između brzine razvoja, održavanja i integracije sa poslovnim sistemima:

• backend servisni sloj: PHP/Laravel ili Node.js, u zavisnosti od klijentovog okruženja
• baza i integracija: MySQL/MariaDB/PostgreSQL
• dokumentacija: OpenAPI
• testiranje: Postman kolekcije + automatizovani testovi
• autentifikacija: token-based pristup, scoped access
• observability: audit log, error log, request tracing
• deployment: odvojena staging i production okruženja

U konkretnom scenariju, preporučen je API koji je nezavisan od frontenda i nezavisan od ERP proizvođača, kako bi buduće izmene bile jeftinije i predvidljivije.

Bezbednost po aktuelnim standardima

Bezbednost nije dodatak na kraju projekta, već osnovni arhitektonski sloj. U ovom slučaju rešenje je projektovano tako da adresira najvažnije rizike koji se redovno pojavljuju kod poslovnih API-ja.

OWASP API Security Top 10 za 2023. posebno naglašava rizike kao što su Broken Object Level Authorization i Broken Authentication, što su dva najčešća problema kod loše projektovanih API-ja. Zato su svi endpointi projektovani tako da provere identitet, prava pristupa i vlasništvo nad objektom pre svake operacije.

Takođe, NIST smernice za zaštitu API-ja u cloud-native sistemima naglašavaju primenu više kontrola nad svakom API komunikacijom, uključujući autentifikaciju entiteta, autorizaciju korisnika i dodatne zaštitne mere van samog identiteta. To je direktno ugrađeno u model ovog rešenja.

Bezbednosne mere u projektu

• HTTPS obavezno za svu komunikaciju
• access tokeni sa ograničenim trajanjem i opsegom prava
• role-based i object-level autorizacija
• validacija svih ulaznih parametara
• rate limiting za osetljive endpointe
• audit trail za promene statusa, porudžbine i pristup kritičnim resursima
• IP restrikcije za sistemske integracije gde je potrebno
• odvojeni tokeni za interne sisteme, partnere i mobilne klijente
• centralno logovanje grešaka i sumnjivih pokušaja pristupa

Zero-trust princip

Zero trust pristup podrazumeva da se nijedan zahtev ne tretira kao automatski bezbedan samo zato što dolazi “iznutra”. NIST Zero Trust Architecture upravo insistira na stalnoj proveri identiteta, konteksta i dozvola za svaki pristup resursu.

Model autentifikacije

Za poslovne sisteme i mobilne aplikacije korišćen je token-based model. Gde je potreban korisnički pristup preko drugih aplikacija, preporučeno je oslanjanje na aktuelne OAuth smernice. OAuth 2.1 je i dalje IETF draft, ali već objedinjuje savremenije bezbednosne preporuke i obsoletuje starije obrasce iz OAuth 2.0 i Bearer Token Usage dokumentacije.

Primer API zahteva

Kreiranje porudžbine

Odgovor

Primer standardizovane greške

Dokumentacija i developer experience

Profesionalan API danas nije potpun bez kvalitetne mašinski čitljive i ljudima razumljive dokumentacije. OpenAPI standard postoji upravo da bi HTTP API mogao da se razume i koristi bez oslanjanja na neformalna objašnjenja, uz minimalnu dodatnu logiku na strani integratora.

Zato isporuka uključuje:

• OpenAPI specifikaciju
• opis svih endpointa
• request/response šeme
• kodove grešaka
• autentifikacione tokove
• Postman kolekciju za brzo testiranje
• sandbox/staging okruženje za partner integracije

KPI i očekivani poslovni efekti

Iako konkretni brojevi zavise od procesa klijenta, ovakav projekat tipično donosi sledeće merljive pomake:

• značajno smanjenje ručnog unosa porudžbina
• brže ažuriranje zaliha i statusa
• manje operativnih grešaka
• bolju dostupnost podataka komercijali i podršci
• kraće vreme obrade porudžbine
• lakše uključivanje novih prodajnih kanala i partnera

Primer rezultata 90 dana nakon puštanja

• ručni unos porudžbina smanjen za 70–90%
• vreme obrade porudžbine skraćeno sa više koraka na jedan automatski tok
• broj reklamacija zbog netačnih statusa ili zaliha vidljivo smanjen
• onboarding novih integracija ubrzan zahvaljujući dokumentovanom API sloju

Ove metrike su realne i uobičajene za firme koje prelaze sa ručnih ili parcijalno povezanih sistema na centralni API model.

Šta je klijent stvarno dobio

Klijent nije dobio samo set endpointa. Dobio je:

• centralni i kontrolisani sloj razmene podataka
• pouzdanu integraciju webshopa, ERP-a, CRM-a i mobilne prodaje
• osnovu za dalju automatizaciju i partner API pristup
• bezbednosni model usklađen sa savremenom praksom
• dokumentovan servis spreman za rast i proširenje
• manji operativni pritisak na zaposlene

Zašto je ovaj case study relevantan za druge firme

Ovaj scenario je veoma blizak realnosti velikog broja firmi u Srbiji i regionu. Mnoge kompanije već imaju više softverskih sistema, ali bez centralnog API sloja ti sistemi ostaju fragmentisani. Upravo zato razvoj REST API servisa postaje jedna od najvažnijih usluga za kompanije koje žele da rastu, uvedu automatizaciju i smanje zavisnost od ručnih procesa.

Savremen REST API servis za biznis nije samo tehnički interfejs između dve aplikacije. To je strateški sloj poslovne infrastrukture koji povezuje prodaju, logistiku, finansije, podršku i mobilne kanale u jednu kontrolisanu, bezbednu i skalabilnu celinu.