Onze boekhouding heet ineens Nmbrs Accounting in plaats van Yuki. Moet er
aan onze koppeling iets veranderen?
Kort antwoord: nee. Yuki heet sinds 1 september 2026 Nmbrs Accounting, maar de API is niet mee verhuisd. Dezelfde webservices op hetzelfde adres, met dezelfde sleutel. Wij bouwden in oktober, dus na de naamswijziging, een koppeling voor een café en die praat met precies dezelfde diensten als een koppeling uit de Yuki-tijd.
Wel handig om te weten wat er hetzelfde bleef, wat je merkt, en waar je bij nieuw bouwwerk op let.
Wat hetzelfde blijft
Het adres. De webservices staan nog op api.yukiworks.nl, per dienst een eigen adres, bijvoorbeeld /ws/Accounting.asmx of /ws/Sales.asmx. Het domein heet nog steeds yukiworks. Pas je adres dus niet aan omdat de naam veranderd is.
De techniek. Het is SOAP 1.1 met de naamruimte http://www.theyukicompany.com/. Wie met SOAP werkte, hoeft niets nieuws te leren. Je hebt er geen speciale SOAP-bibliotheek voor nodig; een zelfgebouwd bericht werkt prima.
De sleutel. Je logt in met de toegangssleutel voor de webservices via Authenticate. Dat geeft een sessie die 24 uur geldig is. Een sleutel hoort bij een domein en ziet de administraties van dat domein.
De limiet. 1.000 aanroepen per domein per dag, en het inloggen telt mee. Wie bij elke vraag opnieuw inlogt, gebruikt dus de helft van zijn ruimte aan inloggen.
Wat je wel merkt
De naam in de schermen, de mails en de facturen van het pakket. En bij het zoeken naar documentatie: die vind je nu onder beide namen, en voorbeelden op internet gebruiken vaak nog de oude.
Belangrijker: Nmbrs heeft ook een API voor salarissen, Nmbrs HR en Payroll. Dat is een ander product met een andere API: REST in plaats van SOAP, een ander adres en een eigen manier van inloggen. Lees je ergens dat de SOAP-API van Nmbrs stopt, kijk dan goed over welk product het gaat. Dat bericht gaat over de salaris-API. Voor Accounting hebben wij geen einddatum gezien, maar houd de berichten van Nmbrs zelf in de gaten.
Waar je op let als je er nu iets op bouwt
Schrijf parameternamen precies over. Een parameter met een verkeerde hoofdletter wordt niet geweigerd maar stil genegeerd. domainId in plaats van domainID geeft geen foutmelding, alleen een leeg of verkeerd antwoord. En de schrijfwijze verschilt per dienst: de verkoopdienst gebruikt sessionId en administrationId, de leesdiensten sessionID en administrationID.
Hergebruik je sessie. Vraag per dienst één sessie aan en bewaar die zolang hij geldig is. Bewaar ook antwoorden die niet elke minuut veranderen een kwartier, zoals openstaande posten. Dan blijf je op een drukke dag ruim binnen de 1.000.
Vraag op tijd extra toegang aan. Voor lezen en voor het aanbieden van verkoopfacturen is de sleutel genoeg. De dienst om inkoopfacturen zelf te boeken vraagt daarnaast een Client ID en Secret, die je via de support van Nmbrs Accounting aanvraagt. Wij hebben die dienst bewust niet nodig: inkoopfacturen zet onze koppeling in de inkoopmap, en Nmbrs herkent en boekt ze daar zelf.
Lees antwoorden ruim. Een element dat er één keer in zit, komt terug als los object; zit het er vaker in, dan als lijst. Een contact-ID kan als lijst van twee gelijke waarden terugkomen. Namen met een & kunnen dubbel gecodeerd zijn. Een parser die op één vorm rekent, breekt op de eerste uitzondering.
Veelgemaakte fouten
De koppeling ombouwen omdat de naam veranderde. Niet nodig. Adres, naamruimte en sleutel zijn gelijk gebleven.
Bij elke vraag opnieuw inloggen. Dat kost per vraag twee aanroepen in plaats van één. Bij 1.000 per dag merk je dat snel.
Een leeg antwoord lezen als "geen gegevens". Het kan ook een verkeerd gespelde parameter zijn. Test elke nieuwe aanroep met een vraag waarvan je het antwoord al weet.
De salaris-API en de boekhoud-API door elkaar halen. Andere API, ander adres, andere aankondigingen. Kijk bij elk bericht over wijzigingen welk product er bedoeld wordt.
Wat wij voor Nmbrs Accounting bouwen, van verkoopfacturen tot een betaalbatch, staat op Nmbrs Accounting koppelen. Hoe we het schrijven naar een boekhouding afbakenen, lees je in acht schrijfacties en geen negende.