Axnify
Za razvijalce

Ecommerce platforma, proti kateri se ti ni treba boriti

Nehaj priviti workaround-e na črno škatlo SaaS. Axnify izpostavi vsak primitiv prek REST-a, pošilja webhook-e za vsak dogodek in ti dovoli urejati kodo teme neposredno. Go v backend-u, Next.js v frontend-u, odprti API-ji povsod.

Zakaj je večina ecommerce SaaS platform sovražna do razvijalcev

Izberi katero koli izmed top 10 commerce SaaS platform in poglej njihovo dokumentacijo API. Nato poglej njihov admin UI. Funkcionalnosti se ne ujemajo. Admin lahko stvari, ki jih API ne more. Hujše, ponudnik platforme to ve — in to šteje za feature, ne bug. Zaklepanje zmožnosti za admin-om je tisto, kar te drži na njihovi platformi. V trenutku, ko lahko vse opraviš prek API-ja, lahko tudi odideš.

To je temeljna napetost. Velike SaaS platforme (Shopify, BigCommerce, Wix Commerce) optimizirajo za netehnične trgovce, ker tvorijo večino njihovega TAM. Ko razvijalci prosijo za webhook na določen dogodek, način registracije custom koraka checkouta ali pisalni dostop do prej read-only vira, je odgovor običajno „nadgradi na enterprise tier“ ali „uporabi Zapier“.

Axnify je zgrajena drugače, ker je njen backend strukturiran za to. Vsaka domena je mikrostoritev (product, order, cart, theme, billing, asset, customer, payment, shipping itd.) s svojo shemo baze podatkov in svojim HTTP API-jem. Admin UI je frontend, ki govori s temi API-ji — natanko tako kot tvoja koda. Ni admin-only zmožnosti. Ni „internega endpointa“, ki ga ne moreš poklicati. Površina API-ja JE platforma.

Ta oblikovalska odločitev ima posledice. Pomeni, da je Axnify bolj iskrena glede tega, kaj podpira in kaj ne: če ni v API-ju, ne obstaja. Pomeni, da se breaking change-i ujamejo hitreje — ne moreš poslati admin feature-a brez pošiljanja API-ja. In pomeni, da ti kot razvijalec, ki se integrira s platformo, nikoli nisi v položaju, da bi moral pisati screen-scraper, ker admin zna nekaj, česar tvoja koda ne.

Zakaj razvijalci zapuščajo velike SaaS platforme

Read-only API-ji, ki se ne ujemajo z admin UI

Lahko listaš izdelke, a ne moreš posodobiti zaloge; lahko bereš naročila, a ne moreš zapolniti fulfillmenta iz svojega ERP-ja. Vsak workaround postane Zapier zanka, ročni CSV izvoz ali screen-scraper, ki se zlomi v trenutku, ko platforma preoblikuje admin.

Koda teme zaklenjena za enterprise tier-i

Shopify zaklepa urejanje teme v Liquid + JS za £2.300/mes Plus načrt. Hočeš se dotakniti HTML-a na £29 načrtu? Uporabi njihov drag-and-drop, kot vsi ostali. Wix ne izpostavlja kode teme na nobenem tier-u. BigCommerce sedi vmes, a zaračunava per-instance za urejanje kode teme.

Webhook-i zamudijo dogodke, ki jih resnično potrebuješ

Splošne platforme oddajo ~15 tipov webhook-ov. Dogodek, ki ga želiš — korak checkouta dokončan, opuščena košarica izpraznjena, tema objavljena, custom field posodobljen, pravica aplikacije spremenjena — običajno ni eden od njih. Končaš na polling-u, kar pomeni glavobole z rate-limit-om in zastarele podatke.

Headless stane dodatno in se zlahka zlomi

„Headless commerce“ na večini platform pomeni ločen enterprise SKU (Shopify Hydrogen, BigCommerce Stencil), drugačno površino API-ja od tiste, ki jo uporablja standardni admin, in ničelno pariteto dokumentacije z admin UI. Pogosto je headless API mesece za admin-om v pokritju funkcij.

Kaj razvijalci dobijo z Axnify

REST API za vsak primitiv

Izdelki, variante, zaloga, kupci, naročila, košarice, teme, strani, sekcije, nastavitve, webhook-i, aplikacije, datoteke, davki — vse CRUD, vse dokumentirano, vse za enim Bearer žetonom. Paginacija, filtriranje in sortiranje sledijo konsistentnim konvencijam na vsakem endpointu.

Webhook-i za vsak dogodek, na vsakem načrtu

Naročilo ustvarjeno, plačano, izpolnjeno, vrnjeno; košarica ustvarjena / opuščena / obnovljena; izdelek / varianta / zaloga posodobljena; tema objavljena; zaposlen povabljen; aplikacija nameščena. Dostava webhook-ov z retry (10 poskusov v 48 urah), HMAC podpisi in log dostave v admin-u.

Vgrajen urejevalnik kode teme

Uredi datoteke teme (HTML / CSS / JS) neposredno v urejevalniku tem admin-a. Zgodovina različic na vsako shranjevanje. Predogled pred objavo. Side-by-side diff proti zadnji objavljeni različici. Rollback z enim klikom, če deploy nekaj zlomi.

Headless-friendly privzeto

Vsak storefront endpoint, ki streže uradni commerce-ui, vrne JSON prek javnega API-ja. Uporabi Next.js, SvelteKit, Astro ali svoj custom frontend, ki kaže na api.axnify.com. Isti API poganja naš privzeti storefront — ni drugorazredne headless API površine.

Marketplace custom aplikacij

Zgradi aplikacijo, jo listaj na marketplace-u, vzemi 80% revenue share. OAuth-flow registracija, scoped dovoljenja, embedded UI paneli v admin-u trgovca, webhook naročnine per namestitev aplikacije, dedicirane dashboard-e aplikacij za analitiko uporabe.

Multi-tenant od prvega dne

Zgrajeno kot multi-tenant SaaS, ne kot single-store namestitev s prilepljenim tenant_id. Izolacija tenant-ov teče prek PostgreSQL row-level security policy, per-tenant object-storage bucket-ov, per-tenant Redis namespace-ov in per-request razreševanja tenant-a v skupnem middleware.

Go backend, sodoben stack

pgx, sqlc, Gin. PostgreSQL za shrambo, Redis za caching, S3-kompatibilen object-storage za assete, Traefik za routing. Brez PHP-ja, brez Rails monolita, sploh brez monolita — več kot 20 mikrostoritev, vsaka neodvisno deployabilna, vsaka s svojimi migracijami in testi.

Stabilen, verzioniran javni API

Vsak primitiv izpostavljen prek REST-a na api.axnify.com — izdelki, variante, zaloga, naročila, košarice, teme, kupci, webhook-i. Dokumentirano, verzionirano in je ista površina, ki jo kličejo uradni admin in storefront-i. Brez internal-only endpoint-ov, brez drugorazrednega headless tier-a.

Kako se arhitektura Axnify razlikuje od monolitnih commerce platform

Klasična arhitektura ecommerce platforme — Shopify, Magento, WooCommerce — je en sam monolitni codebase, ki teče proti eni bazi podatkov. To naredi platformo hitro za začetno gradnjo in lahko za razmišljanje pri majhnih trgovinah. Pomeni tudi, da vsaka feature deli isti runtime, isti pool povezav baze podatkov in isti release cikel. Ko ekipa platforme pošlje novo feature, jo vsak trgovec dobi (ali bug, ki je z njo prišel) isti dan.

Axnify ubere nasprotni pristop. Vsaka commerce domena živi v svoji Go mikrostoritvi. Storitev product ima v lasti izdelke, variante, opcije in zalogo. Storitev order ima v lasti naročila, line item-e in fulfillment-e. Storitev cart ima v lasti aktivne košarice. Storitev asset ima v lasti shranjevanje datotek. Storitev theme ima v lasti teme, strani, sekcije in bloke. Skupaj je takih storitev več kot 20, vsaka s svojo PostgreSQL shemo, svojim direktorijem migracij, svojimi testi, vsaka neodvisno deployabilna.

Storitve komunicirajo prek HTTP-ja z uporabo internal-key avtentikacije za service-to-service klice in JWT/X-Tenant-ID za klice, ki izvirajo od končnega uporabnika. Skupne skrbi (auth, razreševanje tenant-a, rate limiting, logiranje, metrike, error tracking) živijo v skupnem middleware paketu, ki ga uvozi vsaka storitev. PostgreSQL je skupen, sheme pa so izolirane; storitev lahko JOIN proti tabelam druge prek views, zapisi pa gredo skozi API lastniške storitve.

Za tebe kot razvijalca, ki se integrira s platformo, ima ta arhitektura praktične posledice. API-ji so stabilni per-storitev: product API se razvija s svojim tempom, order API s svojim. Webhook-i prihajajo iz storitve, ki ima v lasti dogodek, z bogatimi metapodatki o tem, katera storitev je kaj oddala. Performanse so omejene per-domena: počasen poročilni query v analytics storitvi ne more blokirati tvojega order-create klica. In debugiranje je lažje, ker vsak request nosi request ID, ki se logira v vsaki storitvi, ki se je dotakne.

Kaj razvijalci gradijo na Axnify

Custom checkout pretoki

Preskoči privzeti checkout v celoti. Vodi custom React/Vue checkout iz cart in payment API-jev, medtem ko še naprej uporabljaš Axnify za zalogo, davke in fulfillment navzdol. Cart API ti daje polno kontrolo nad tem, kaj se zgodi na vsakem koraku.

ERP / OMS integracije

Dvosmerna sinhronizacija z NetSuite, SAP B1, Dynamics 365. Webhook-driven inkrementalne posodobitve push-ajo nova naročila v tvoj ERP v realnem času; bulk REST endpoint-i rešujejo nočne uskladitve. Idempotency ključi na vsakem zapisu, da so retry-ji varni.

Interna orodja trgovca

Zgradi admin panele, ki jih tvoja CS ekipa resnično želi uporabljati. Uporabi staff API tokene s scoped dovoljenji; admin trgovca in tvoja custom orodja koeksistirajo. Read-only views se lahko dodelijo podpori, ki ne sme imeti polnega admin dostopa.

Multi-frontend deploy-ji

Isti katalog izdelkov, več storefront-ov (web, mobilna aplikacija, in-store kiosk, glasovni asistent). Vsak konzumira isti API; Axnify je vir resnice. Cache invalidation dogodki se sprožijo, ko se izdelek spremeni, da lahko vsak frontend ponovno pridobi podatke.

Pogosta vprašanja razvijalcev

Ali obstaja GraphQL API?

Danes samo REST. Tehtali smo GraphQL med arhitekturo in izbrali REST zaradi cacheability (HTTP semantika, CDN-friendly), enostavnejših klientskih knjižnic in lažjega debugiranja. Če je GraphQL trd pogoj za tvojo ekipo, sta Saleor ali Vendure danes boljša izbora.

Kakšni so rate limit-i API-ja?

1.000 req/min na API token na Starter-ju, 10.000 na Pro, neomejeno (samo fair-use) na Business+. Bulk endpoint-i (npr. uvoz izdelkov) so izvzeti iz per-minute capa in namesto tega rate-limited po skupnih bajtih na uro. Rate-limit zaglavja (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`) so vrnjena na vsak odgovor.

Je Axnify open source ali self-hostable?

Ne — Axnify je popolnoma managed SaaS. Mi poganjamo in upravljamo platformo, da se ti lahko osredotočiš na gradnjo svoje trgovine in svojih integracij. Vsaka zmožnost je izpostavljena prek javnega REST API-ja in webhook-ov na api.axnify.com, zato za razširitev ali integracijo ne potrebuješ strežniškega dostopa.

Kako se plačujejo naročnine na aplikacije?

Stranka se naroči prek admin-a trgovca → Stripe rešuje billing → Axnify vzame 20% provizije platforme → 80% se izplača na tvoj povezan Stripe račun tedensko. Vračila in chargeback-i se vračajo po isti poti. Razvijalci aplikacij vidijo svoje prihodke v dediciranem dashboard-u z zgodovino izplačil.

Kako se avtenticiram proti API-ju?

Ustvari Personal Access Token v admin-u pod Developers → API tokens. Posreduj ga kot `Authorization: Bearer <token>` na vsakem requestu. Tokeni nosijo scoped dovoljenja (read-only, read-write, admin), potečejo po urniku, ki ga izbereš, in se lahko takoj prekličejo z istega zaslona.

V katerem jeziku / framework-u so napisane teme?

Teme so JSON-definirana drevesa blokov, renderirana s skupnim TypeScript renderer-jem (commerce-ui). Privzeta knjižnica blokov pokriva ~40 tipov widget-ov; lahko pošlješ custom widget-e tako, da napišeš React komponento in jo registriraš prek aplikacije. Koda teme je editabilna per-trgovec v urejevalniku tem admin-a.

Mi lahko pomagate prestaviti podatke z druge platforme?

Seveda. Piši na support@axnify.com z export datoteko iz svoje trenutne platforme — sprejemamo Shopify, WooCommerce, Etsy, Squarespace, Big Cartel, Gumroad, Sellfy in večino drugih običajnih formatov. Naša ekipa vodi migracijo tvojih izdelkov, variant, strank in naročil end-to-end, brezplačno za standardne uvoze.

Nehaj se boriti s svojo ecommerce platformo

Registriraj se brezplačno, dobi API token v 60 sekundah, začni integrirati.