Our accounting package is suddenly called Nmbrs Accounting instead of Yuki.
Does anything need to change in our integration?
Short answer: no. Yuki has been called Nmbrs Accounting since 1 September 2026, but the API did not move with it. The same web services at the same address, with the same key. In October, after the name change, we built an integration for a café, and it talks to exactly the same services as an integration from the Yuki days.
It is still useful to know what stayed the same, what you will notice, and what to watch for with new work.
What stays the same
The address. The web services are still on api.yukiworks.nl, with a separate address per service, for example /ws/Accounting.asmx or /ws/Sales.asmx. The domain is still called yukiworks. So do not change your address because the name changed.
The technology. It is SOAP 1.1 with the namespace http://www.theyukicompany.com/. If you have worked with SOAP, you do not need to learn anything new. You do not need a special SOAP library for it; a message you build yourself works fine.
The key. You log in with the access key for the web services through Authenticate. That gives a session that is valid for 24 hours. A key belongs to a domain and sees the administrations of that domain.
The limit. 1,000 calls per domain per day, and logging in counts. If you log in again for every question, you use half of your allowance on logging in.
What you will notice
The name in the screens, the emails and the invoices of the package. And when you search for documentation: you now find it under both names, and examples on the internet often still use the old one.
More important: Nmbrs also has an API for payroll, Nmbrs HR and Payroll. That is a different product with a different API: REST instead of SOAP, a different address and its own way of logging in. If you read somewhere that the SOAP API of Nmbrs is ending, look closely at which product it is about. That message is about the payroll API. For Accounting we have not seen an end date, but keep an eye on the announcements from Nmbrs itself.
What to watch for if you build on it now
Copy parameter names exactly. A parameter with the wrong capital letter is not rejected but silently ignored. domainId instead of domainID gives no error, only an empty or wrong response. And the spelling differs per service: the sales service uses sessionId and administrationId, the read services sessionID and administrationID.
Reuse your session. Request one session per service and keep it as long as it is valid. Also cache responses that do not change every minute for a quarter of an hour, such as open items. Then you stay well within the 1,000 on a busy day.
Request extra access in time. For reading and for submitting sales invoices the key is enough. The service for booking purchase invoices yourself also needs a Client ID and Secret, which you request through the support of Nmbrs Accounting. We deliberately do not need that service: our integration puts purchase invoices in the purchase folder, and Nmbrs recognises and books them there by itself.
Read responses generously. An element that occurs once comes back as a single object; if it occurs more often, as a list. A contact ID can come back as a list of two equal values. Names with an & can be encoded twice. A parser that counts on one shape breaks on the first exception.
Common mistakes
Rebuilding the integration because the name changed. Not needed. Address, namespace and key stayed the same.
Logging in again for every question. That costs two calls per question instead of one. At 1,000 a day you notice that quickly.
Reading an empty response as "no data". It can also be a misspelt parameter. Test every new call with a question whose answer you already know.
Mixing up the payroll API and the accounting API. Different API, different address, different announcements. For every message about changes, check which product is meant.
What we build for Nmbrs Accounting, from sales invoices to a payment batch, is on connecting Nmbrs Accounting. How we limit writing to an accounting package, you can read in eight write actions and no ninth.