How to create OAuth credentials for Twinfield

This guide walks you through Wolters Kluwer's API certification, registering your own Twinfield OAuth client, and adding its Client ID and Secret to the Apideck Dashboard so your integration can run in production.

Two things to know before you start:

• A free Wolters Kluwer Account is your login for everything on the Twinfield side. Create it as a non-personal, shared account that represents your application — not an individual employee's account, and not one belonging to a customer whose administration you will connect to. One Wolters Kluwer Account and one Client ID cover both your test and production use.
• Everything past that account runs through Wolters Kluwer's Certified Partner subscription. Developer Portal access, a Test Environment and support-portal access are granted when you sign the certification order form, so registering your OAuth client follows the application rather than preceding it. Before that point you can read Twinfield's public API documentation, plan your mappings and error handling, build your own UI, and register the Wolters Kluwer Account itself — the parts that need a live Twinfield administration wait for the signed order form.

1. Apply for certification and sign the order form

1. Apply. Submit the partner application form (Dutch-language, "Stap 1: Aanmelden") to request a certification subscription. A Partner Sales Manager follows up with you.
2. Sign the order form. Signing gives you access to the Twinfield developer portal, a Test Environment, and the support portal where you can raise cases with Twinfield's technical support team. This is the point at which you can register your OAuth client and start building against a real Twinfield administration.

Certification is a monthly subscription and Wolters Kluwer does not publish a figure, so confirm the price with the Partner Sales Manager during the application conversation — and ask them for an expected timeline so you can plan the rest of the build around it. Sections 2 to 5 below are what you do once the order form is signed; the remaining certification steps are in section 6.

2. Register your OAuth client

1. Go to the Twinfield developer portal and sign in with your Wolters Kluwer Account.

2. Register a new OpenID Connect / OAuth 2.0 client for your application. Fill the registration form in as follows:

   Field	What to enter
   Client ID	The identifier for your client. This is the value you paste into the Apideck Dashboard in section 5, and the value Wolters Kluwer certifies in section 6.
   Product name	Your application's name — end users see it when they are asked to grant permission.
   Authorization flow	Select authorization code. This is the flow the connector uses.
   Access token type	Keep the default, Reference — see the note below.
   Ignore single sign on	Check this box. Twinfield's registration documentation says to enable it so that creating an OAuth 2.0 connection does not fail with an error requiring the user to log in with Single Sign On (SSO).
   Redirect url	https://unify.apideck.com/vault/callback — see section 3.

   Leave anything else at its default; Twinfield documents Post logout redirect url as unavailable.

3. Generate a Client Secret with the Generate new link and store it somewhere safe as soon as it is shown.

Why to keep the default (Reference). Twinfield's own registration guidance lists Reference as the default option to select, with Jwt offered as an alternative that returns a longer token — it does not document a functional reason to change it for an OAuth integration, so there is no reason to deviate from the default here. Separately, and regardless of which token type is registered: Twinfield routes each organisation to its own cluster host, and the connector discovers that host by validating the access token against Twinfield's token-validation endpoint and reading the cluster claim from the result. If that lookup does not return a cluster for any reason, the connector falls back to the default api.accounting host and keeps going without surfacing an error — so a failed lookup can send a customer's requests to the wrong cluster with no visible failure to trace it back from. If a customer reports unexplained failures or unexpected/empty results, this silent fallback is the first thing to rule out; contact Apideck Support to investigate.

Twinfield's own references for this step are Setting up OAuth 2.0 — Register a client ID and the OpenID Connect authentication documentation.

3. Set the redirect URL

Enter this value in the Redirect url field on your Twinfield client:

https://unify.apideck.com/vault/callback

This is the only redirect URL Apideck uses. Do not register a localhost or vendor-specific URL — the authorization will fail if the value Twinfield has on file does not match exactly, including the presence or absence of a trailing slash.

4. Scopes — nothing to configure

You do not need to enable scopes anywhere. Twinfield's client registration form has no scope selection; scopes are requested per authorization request, and the Apideck connector already requests all five that a Twinfield integration needs:

Scope	Why it is needed
openid	Required alongside twf.user for OpenID Connect authentication
twf.user	User claims (id, organisation user code, organisation id)
twf.organisation	Organisation claims, including the cluster URL the connector needs to route requests
twf.organisationUser	Mandatory in order to log in
offline_access	Required to receive a refresh token — without it, connections stop working after the access token expires

twf.organisation is not optional in practice: Twinfield routes each organisation to its own cluster host (for example api.cluster9.twinfield.com), and the connector resolves that host from the organisation claims after the token exchange.

5. Add the credentials in Apideck

1. Open the Twinfield connector configuration in the Apideck Dashboard.
2. Select Use your own client credentials.
3. Enter:
   • Client ID → the Client ID from your Twinfield developer portal client
   • Client Secret → the matching secret
4. Save the settings.

Apideck also ships managed credentials for Twinfield. These are an uncertified Client ID — capped at 5% of the normal API budget under Twinfield's fair use policy — for development and testing only, not a substitute for your own certified Client ID in production. Use your own Client ID for production: Twinfield grants certification to a specific ClientId and enforces rate limits per ClientId, so the certification you complete in section 6 applies only to the client you registered.

6. Complete Wolters Kluwer's certification

A production Twinfield integration runs on a certified Client ID. Until certification is complete, your Client ID is allowed only 5% of the normal API budget, cannot be published to the Twinfield marketplace, and is deactivated if the certification subscription is not taken out within two weeks of Wolters Kluwer's notice. The full budget table is in Twinfield's fair use policy.

Picking up from the signed order form in section 1, the remaining steps are:

3. Complete the technical questionnaire that the certification consultant sends you.
4. Review with the consultant. The consultant reviews the questionnaire and tells you about any changes or improvements needed.
5. Receive the certificate once all findings are resolved. Certification is granted to your organisation and its ClientId.

Twinfield's own write-up of these steps is the article What is covered during certification.

Certification is renewed every two years. Wolters Kluwer re-certifies the API integration on a two-year cycle, so budget for the audit as an ongoing commitment rather than a one-off.

7. Track the per-customer values your integration needs

Twinfield connections carry a few values that are specific to each customer's administration, not to your OAuth app. Collect them as part of your customer onboarding so a connection can be completed without a round-trip.

Setting	What it is	Default
Office code	The Twinfield office (administration) code the connection operates against, e.g. 1000. Twinfield references companies by code, not by numeric ID, and this code is sent on every authenticated request.	none — ask the customer
Accounts payable control account	The ledger account code Twinfield uses for amounts owed to suppliers. Required by Twinfield on every bill.	1600
Accounts receivable control account	The ledger account code Twinfield uses for amounts owed by customers. Required by Twinfield when recording a customer payment.	1300

The two control accounts only need to be set when a customer's chart of accounts differs from Twinfield's standard one. Leave them blank and the defaults above are used. Twinfield exposes no API to look these codes up, so if a customer is on a customized chart of accounts, the correct values have to come from the customer or their accountant.

One connection targets one office code. A customer whose organisation spans several administrations needs one connection per office.

FAQ and troubleshooting

The authorization fails or returns a redirect mismatch. Check that https://unify.apideck.com/vault/callback is registered on the Twinfield client exactly, with no trailing slash, and that you configured the same Client ID in the Apideck Dashboard that you registered the redirect URL on.

Requests fail unexpectedly, or return unexpected/empty results. The connector resolves each organisation's cluster host from the access token, and falls back to the default api.accounting cluster without an error if that lookup fails for any reason — so requests can silently reach the wrong cluster. Contact Apideck Support to investigate; this is not something you can diagnose or fix from the Twinfield client registration alone.

Authorization fails with an error saying the user must log in with Single Sign On. Check the Ignore single sign on box on your Twinfield client registration and have the customer authorize again.

Connections work at first, then stop refreshing. Twinfield invalidates a refresh token immediately, with no advance warning, when the underlying Twinfield organisation user is deleted, disabled, or locked, when that user's password expires, or when the organisation itself is deactivated. The first sign is an invalid_request or invalid_grant error on the next refresh. The fix is on the customer's side: restore or replace the Twinfield organisation user, then reconnect. To avoid this, ask customers to authorize with a service account rather than an individual's login.

We are hitting HTTP 429 responses. Check first whether your Client ID is certified — an uncertified Client ID is capped at 5% of the normal budget. Twinfield returns X-RateLimit-* headers on every call and a Retry-After header on rate-limit rejections, so you can see the remaining budget directly in the response. Twinfield states that it does not grant limits above the published values.

Bills or payments post to the wrong ledger account. Check the accounts payable / accounts receivable control account settings on that connection against the customer's chart of accounts. The defaults (1600 and 1300) are correct only for Twinfield's standard chart of accounts.

Where do I get help? For questions about certification, your subscription, or a Twinfield administration, contact your Wolters Kluwer Partner Sales Manager or the Twinfield support portal you received access to when the order form was signed. For questions about the connector or the Apideck Dashboard, contact Apideck Support.