E-handlarnas Ullared – ett digitalt fyndvarhus där ”hyllvärmare” säljs till vrakpris. Det är den enkla men briljanta affärsidén bakom Fyndiq. Sedan starten 2010 har drygt 1 500 ­e-handlare nått nya kunder genom Fyndiqs välbesökta portalsajt.

Fyndiq sköter marknadsföring och försäljning och tar hand om betalningen – och skickar sedan pengar till handlaren. Den tekniska basen – och en viktig framgångsfaktor – är api:erna, gränssnitten, som gör det enkelt att lägga upp produkter.

– Det är så vi integrerar ­e-handlare och plattformar, så det är centralt för vår affärsmodell, säger Patrik Svennerstam, som är Fyndiqs cto.

Läs mer: Så jobbar Fyndiq med A/B-tester

Praktiskt går det till så att den som vill sälja produkter via Fyndiq sluter ett handlaravtal som ger tillgång till Fyndiqs api:er. Sedan är det möjligt att koppla upp sig på lite olika sätt. Antingen via en open source-plattform, typ Magento, eller via en avgifts­belagd plattform, som Askos.

– Eller så har handlaren en egen plattform som integreras mot vår, förklarar Patrik Svennerstam.

Fyndiqs api:er är det man brukar kalla ”halvöppna”. Enbart partners som har registrerat sig har tillgång till dem. Och så lär det sannolikt förbli.

– Hela vår affär bygger ju på att vi ska sälja åt de handlare som integrerar mot oss. Och för att säkra kvali­teten för slutkunden måste vi veta vilka vi gör affärer med, så att produkterna är säljbara, säger Patrik.

Så ser det ut när det gäller handeln mot konsument, b2c. Men Fyndiq har också ett affärsområde som sysslar med handel b2b, business to business, och här kan man tänka sig att api:erna framöver blir mer öppna.

– Än har vi inte sett något behov, men på sikt kan man ju tänka sig att det finns handlare som skulle vilja bygga en egen app som gör det möjligt att övervaka försäljning i mobilen och då kan det komma till pass. Därför ser vi till att inte bygga fast oss, så att vi har möjlighet att öppna upp api:erna om det efterfrågas.

Fyndiq har vuxit kraftigt sedan starten och en viktig lärdom man dragit är att ”one size does not fit all”.

Video: Fyndiq: ”Vi är inte störst men vi kan springa snabbast”

– För att kunna växa och ta in fler e-handlare måste vi skapa nya api:er som kan hantera stora volymer och skiftande behov utan att krångla till det, säger Patrik Svennerstam.

– Det kan exempelvis handla om hur man arbetar med reklamationer. Vissa företag har specifika processer som de vill följa och det vill vi kunna stödja, vilket kan vara en anledning att öppna våra api:er, säger han.

En stor utmaning är att hantera tillväxten. Härom året gick man in på den tyska marknaden, som är tio gånger större än den svenska, vilket ställer höga krav på skalbarhet.

– Så våra api:er måste vara tydliga och väldokumenterade, så att det är enkelt för våra kunder att hålla koll.

För att hamna rätt har Fyndiq koppat in folk från både it och marknad. Teknikorganisationen tillhandahåller själva api:erna, och de moduler som används mot e-handelsplattformarna. Marknadssidan har en avdelning som kommunicerar med kunderna, tar in respons och fångar upp nya handlare som är intresserade av att göra affärer med Fyndiq.

– De hjälper till med ”onboardin­gen” både tekniskt och ur affärsperspektiv, de coachar kunderna och tittar på hur vi kan få till merförsäljning.

Den som vill skapa ett eget api bör först och främst tänka på att allt ska vara väldokumenterat. Det måste vara enkelt för den som integrerar att förstå vilka tekniska krav som ställs, menar Patrik Svennerstam.

– Det är också viktigt att förstå behovet hos den som ska integrera, så att man tillhandahåller ett api som uppfyller kundens affärskrav.

– Det är därför vi nu rör oss från våra tidiga api:er, där allt fungerade likadant oavsett vilken plattform man kopplade upp sig från, till mer flexibla api:er. De som integrerar mot oss får mer att säga till om, och på så sätt kan vi skräddarsy lösningar.

Patrik Svennerstams api-tips

1. Dokumentera väl, så den som använder api:et kan göra integra­tionen på egen hand. Det minimerar supportbehovet.
2. En genomtänkt strategi för versionshantering och bakåtkompatibilitet vid uppgradering av api:et sparar tid och pengar – hos både kund och leverantör. 
3. Se till att de api:er som utvecklas levererar kundvärde och byggs som kunden vill ha dem. api:er som sällan eller aldrig används är dåliga investeringar.