Koppeling nieuwe webwinkel/kassa platform: Noodzakelijke voorwaarden API winkelplatform

Deze vraag is bedoeld voor software leveranciers - niet voor (web)winkeliers/restauranthouders.

Hieronder staat beschreven waar de API van een webwinkel- of kassa-systeem aan moet voldoen als wij de integratie doen. Momenteel zijn we echter druk bezig een eigen API te ontwikkelen hetgeen de software leverancier in staat stelt zelf één enkele  integratie te doen (naar onze API) en zodoende ontsluiting naar alle boekhoudpakketten te krijgen. Indien je hier interesse in hebt, neem dan contact met ons op.

API verwachtingen als wij de integratie doen.

Bij het koppelen naar een nieuw webwinkelsysteem dient de API van het webwinkelplatform aan de volgende voorwaarden te voldoen:

  1. We koppelen alleen met REST API.
  2. De webwinkel moet online benaderbaar zijn. Wij koppelen niet met hybride systemen waarbij de bestellingen offline beschikbaar zijn en worden doorgezet naar een cloudomgeving. De reden is dat dit de supportprocessen te zwaar zou belasten.
  3. De REST API dient gedocumenteerd te zijn. In het bijzonder dient de omschrijving van de velden en het feit of een veld verplicht is, te zijn gedocumenteerd. De documentatie dient overzichtelijk te zijn en te zijn opgezet met Swagger of een vergelijkbare API documentatie tool.
  4. Authenticatie bij voorkeur met OAuth. Een voorbeeld van het opzetten van OAuth met alle requests dient uitgeschreven te zijn.
  5. Er dienen endpoints te zijn voor:
    1. Debiteuren - zoeken op emailadres
    2. Verkopen - zoeken op id en periode, bij voorkeur ook zoeken op nummer
    3. De verkoopregels zijn voorzien van BTW informatie
    4. Verzendkosten, betaalkosten, kortingen en toeslagen zijn voorzien van BTW informatie
    5. Producten - zoeken op id en op SKU
    6. BTW tarieven zijn op te halen uit de webwinkel
    7. Betaalmethoden zijn op te halen uit de webwinkel
    8. Bij het wijzigen van een bestelling wordt het bestel-id niet gewijzigd
  6. Responses vanuit de webwinkel dienen aan te geven of een request geslaagd of niet geslaagd is.
  7. Is een actie niet geslaagd dan is de HTTP response code 400 en bevat de response een omschrijving van wat er verkeerd is gegaan
  8. Er zijn ruime API limieten of het moet mogelijk zijn om de ruimte binnen de API limiet te berekenen.
  9. Support: wij verwachten (i) dat technische problemen via een emailalias / support tool gelogd kunnen worden, (ii) een Nederlandse contactpersoon bij support, (iii) dat we transacties uit kunnen lezen op basis van een kenmerk of een referentie en (iv) na het melden van een technisch probleem binnen 1 werkdag een antwoord. Bij grote impact op eindgebruikers is het doel eventuele problemen zsm op te lossen.

Bij het koppelen van een nieuw kassaplatform dient de API van het kassa-platform aan de volgende voorwaarden te voldoen:

  1. We koppelen alleen met REST API.
  2. De kassa moet online benaderbaar zijn. Wij koppelen niet met hybride systemen waarbij de bonnen offline beschikbaar zijn en worden doorgezet naar een cloudomgeving. De reden is dat dit de supportprocessen te zwaar zou belasten.
  3. De REST API dient gedocumenteerd te zijn. In het bijzonder dient de omschrijving van de velden en het feit of een veld verplicht is, te zijn gedocumenteerd. De documentatie dient overzichtelijk te zijn en te zijn opgezet met Swagger of een vergelijkbare API documentatie tool.
  4. Authenticatie bij voorkeur met OAuth. Een voorbeeld van het opzetten van OAuth met alle requests dient uitgeschreven te zijn.
  5. Bonnen van een dag dienen uiterlijk om 05.00 de volgende dag beschikbaar te zijn voor het doorzetten van de dagomzet.
  6. Bonnen dienen op te tellen. De bedragen in de bonregels dienen op te tellen tot het totaal van de bon. De som van de betalingen dient overeen te komen met de som van de omzet.
  7. Er dienen endpoints te zijn voor:
    1. Bonnen - zoeken op id en periode, bij voorkeur ook zoeken op nummer
    2. De bonregels zijn voorzien van BTW informatie, productcode en categorie-id
    3. BTW tarieven zijn op te halen uit de kassa
    4. Betaalmethoden zijn op te halen uit de kassa
    5. Categorieen zijn op te halen uit de kassa
  8. Responses vanuit de kassa dienen aan te geven of een request geslaagd of niet geslaagd is.
  9. Is een actie niet geslaagd dan is de HTTP response code 400 en bevat de response een omschrijving van wat er verkeerd is gegaan
  10. Er zijn ruime API limieten of het moet mogelijk zijn om de ruimte binnen de API limiet te berekenen.
  11. Support: wij verwachten (i) dat technische problemen via een emailalias / support tool gelogd kunnen worden, (ii) een Nederlandse contactpersoon bij support, (iii) dat we transacties uit kunnen lezen op basis van een kenmerk of een referentie en (iv) na het melden van een technisch probleem binnen 1 werkdag een antwoord. Bij grote impact op eindgebruikers is het doel eventuele problemen zsm op te lossen.

Labels: Webwinkelfacturen.nl