Yuki is a cloud boekhouden platform built for SMEs and accounting practices in the Netherlands, Belgium, and Spain. If you're building a product that needs to push invoices, sync contacts, or pull financial data for a Yuki user's administration, you're going to work with a SOAP API. That's worth knowing upfront: Yuki does not have a REST interface. Every call goes through SOAP over HTTPS, which means envelope XML, namespaces, and a session-based auth flow rather than a bearer token.

Setting up a Yuki koppeling involves two parts: getting the right credentials from inside the Yuki portal, and structuring your SOAP requests correctly. This post covers both, along with the available webservices, the rate limits you need to plan around, and what to watch for when building for multiple customers.

Authentication: two credentials, one session

Yuki's API uses a two-step authentication model. You first call Authenticate(accessKey) with a WebserviceAccessKey, which returns a session ID. That session ID is then passed along with an Administration ID on every subsequent call.

The WebserviceAccessKey is generated inside the Yuki portal under the Web services settings for the domain or administration. Only users with Portal Administrator or Management roles can generate one. If you're building a product where your customers connect their own Yuki accounts, each customer needs to provide their own key. Yuki's API does not support a centralized OAuth flow where your application requests delegated access on behalf of users.

There's also a second auth method, AuthenticateByUserName(userName, password), which accepts Yuki credentials directly, but the access key route is preferable. Keys can be rotated without changing credentials, and they scope permissions to specific webservices rather than granting full account access.

Here's a minimal PHP example using the Sales webservice:

$webservice_url = 'https://api.yukiworks.nl/ws/Sales.asmx?WSDL';
$key = 'YOUR_WEBSERVICEACCESSKEY';
$admin_id = 'YOUR_ADMINISTRATIONID';

$soap = new SoapClient($webservice_url);
$res = $soap->Authenticate(['accessKey' => $key]);
$sess_id = $res->AuthenticateResult;

$res = $soap->ProcessSalesInvoices([
    'sessionID'        => $sess_id,
    'administrationId' => $admin_id,
    'xmlDoc'           => $invoiceXml
]);

Two things to note: the session ID comes back inside an AuthenticateResult field, not a top-level response value, and the xmlDoc parameter expects a namespaced XML structure, not a flat payload.

The available webservices

Each Yuki webservice covers a distinct data domain, accessed at separate ASMX endpoints under https://api.yukiworks.nl/ws/.

The Accounting webservice (Accounting.asmx) handles financial data exports and general journal creation. The ProcessJournal method takes an XML document describing journal entries against GL accounts, which is the primary route for pushing bank transactions, write-offs, or custom entries from an external system. The AccountingInfo webservice (AccountingInfo.asmx) lets you read GL account schemes and retrieve transaction details.

The Sales webservice (Sales.asmx) creates sales invoices via ProcessSalesInvoices. The XML payload includes fields for invoice lines, customer references, tax codes, and payment terms. Linking invoices to projects requires the Medium bundle or higher on the customer's Yuki account.

The Contact webservice handles search, create, and update operations for customers and suppliers. The Archive webservice lets you push documents with financial metadata and pull documents back out. The Upload webservice is for attaching source documents (PDFs, images) to records. Pettycash handles cash report imports, and the Project webservice creates and updates project records.

One webservice that sits outside the standard API key flow: the Purchase webservice. To get access, you need to send a formal request to support@yuki.nl, after which Yuki issues a Client ID and Secret used alongside the regular API key. There is no self-service activation path for this one.

Rate limits and batching

The default quota is 1,000 SOAP calls per day per Yuki domain. A portal administrator can raise that ceiling through two paid add-ons: "Yuki Webservice" extends it to 5,000 calls/day for €10.50/month, and "Yuki Webservice Extended" pushes to 10,000 calls/day for €105/month.

A thousand calls per day is tighter than it sounds if you're polling for updates or syncing large transaction histories. Design around batch operations from the start. ProcessSalesInvoices accepts multiple invoices in a single XML document, so there's no reason to make one call per invoice. The same applies to journal entries and contact records.

If you're building a multi-tenant product where each customer has their own Yuki administration, the 1,000-call limit applies per domain, not per API key. One heavily active customer won't consume another's quota, but you still need per-administration rate tracking if you want to avoid hitting the ceiling for any individual customer.

Working with SOAP in practice

SOAP has a reputation for being painful, and Yuki's implementation has a few rough edges worth knowing about.

TLS 1.2 or higher is required. Yuki enforced this in April 2019 and will reject connections on older versions.

The namespaces in the XML payloads need to match exactly. The sales invoice XML uses urn:xmlns:http://www.theyukicompany.com:salesinvoices, and the journal XML uses urn:xmlns:http://www.theyukicompany.com:journal. Mismatched or missing namespace declarations are a common source of silent failures that can be difficult to diagnose.

Modern SOAP clients (PHP's SoapClient, Python's zeep, Node's soap package) can parse the WSDL endpoint and generate the correct envelope structure automatically. Pointing your client at the ?WSDL URL for the relevant service is the fastest way to get started without hand-writing envelopes.

If you're building for multiple accounting systems

Yuki is the dominant cloud boekhouden platform in the Netherlands and Belgium, but if you're trying to cover the broader European accounting software market, each platform runs its own authentication model, data schemas, and rate limits. Connecting to them one at a time compounds fast, and European accounting is a fragmented market by design.

One option is to build the Yuki integration through Apideck's Accounting API, which maps Yuki's data model to a standardized interface shared across 200+ connectors. Your code sends and receives normalized objects (invoices, contacts, journal entries, ledger accounts), and Apideck handles the SOAP translation, session management, and per-user credential storage on the Yuki side. You can see how the Yuki connector is structured, or explore how similar integrations like Exact Online work through the same interface if you're covering multiple Benelux platforms.

Either way, the Yuki API is well-documented relative to what you'd expect from a regional accounting tool. The official documentation lives at Yuki's Postman collection, sample code for PHP and C# covers the most common operations, and the webservice structure is consistent once you understand the session model. The SOAP overhead is real, but manageable once you have the session flow and namespace handling sorted.

---

FAQ

How do I get a Yuki API key?

In Yuki, go to Settings > Web services (or navigate via My Domain > Administration > Web services). Click the + button to generate a new WebserviceAccessKey. You'll also see the Administration ID here, which you'll need alongside the key for every API call. Only Portal Administrator or Management role users can generate keys.

What is the Yuki API rate limit?

By default, each Yuki domain is capped at 1,000 SOAP calls per day. Your accountant can activate the "Yuki Webservice" add-on to raise this to 5,000 calls/day (€10.50/month) or "Yuki Webservice Extended" for up to 10,000 calls/day (€105/month).

Does Yuki have a REST API?

No. Yuki's API is SOAP-only. All calls are made to ASMX endpoints over HTTPS, and every request requires a valid session ID obtained through the Authenticate method.

What is a Yuki koppeling?

A Yuki koppeling (Dutch for "Yuki connection" or "Yuki integration") is the term used in the Dutch market for connecting external software to a Yuki administration via the webservice API. Setting one up requires generating a WebserviceAccessKey and Administration ID from within the Yuki portal.