How to obtain and configure your Procountor API credentials

This guide is for you, the Apideck customer building an integration. It covers requesting credentials from Procountor, turning them into the access token the connector uses, validating your integration on Procountor's Public Testing Server, and entering the token in your Apideck connector settings.

Procountor issues credentials to your integration on request. They arrive in two batches — testing first, production once your integration is validated against the testing server — and this guide follows that order.

There is no Apideck-provided sandbox app for this connector, so you supply your own credentials before any consumer can connect.

Before you start

A Procountor contact, or a willingness to start cold through the integrations form in step 1 — credentials are issued per integration, not generated by you.
An Apideck account with the Procountor connector enabled.
A rough list of the accounting data your integration needs. Procountor's integrations team asks what you are building, and the answer shapes what they provision.
Somewhere to run a server-to-server token request. Procountor's credentials are exchanged for an access token by your own backend, not by Apideck (see step 3).

1. Request integration credentials from Procountor

Submit a contact request on Procountor's integrations page:

Procountor integrations and API — contact form

That page also lists liittymat@procountor.com as the direct route to the integrations team if you prefer email or the form does not fit your case. Describe the integration you are building, the Procountor data it reads and writes, and whether you are integrating on behalf of your own customers.

Procountor's machine-to-machine flow issues an integration partner a client ID and a client secret, described on M2M authentication. These are yours to hold and exchange — they are not the values you enter in Apideck. Store them in your secret manager as soon as you receive them.

Do not be surprised if this credential set arrives with the testing environment in step 2 rather than as a separate delivery: Procountor's own documentation describes the client ID and client secret as values you are given when you request a testing environment. The two requests can resolve into one credential handover.

2. Request a private testing environment

In parallel, register as a developer to get a test environment and credentials for the Public Testing Server:

Request Testing Environment

Procountor describes this as: "Register as a developer. We'll provide you with a private testing environment and credentials for accessing our API testing server." Using the API endpoints and the UI features in the testing environment is free of charge.

This is the step that actually unblocks development — you cannot build against production first.

3. Exchange your credentials for an access token, and configure it in Apideck

The Apideck connector authenticates with a single bearer access token. It does not hold your client ID and client secret, and it does not perform the token exchange or refresh the token for you — that exchange is yours to run, following Procountor's M2M authentication documentation.

The token request

In outline, per that page: your backend posts to /api/oauth/token with grant_type=client_credentials, your client_id and client_secret, and an api_key.

That path sits on the API host of the environment you are authenticating against, so the endpoint you post to changes with the environment — and the environment has to match the credentials you were issued:

Environment	Token endpoint
Testing — while you are validating (steps 3–4)	`/api/oauth/token` on the testing host Procountor issued you. The connector declares that host as `https://api-test.procountor.com`; read step 4 before assuming that is the address in your own credential set.
Production — once you go live (step 5)	`https://api.procountor.com/api/oauth/token`

Testing credentials do not authenticate against the production host and production credentials do not authenticate against the testing host, so check the pair before you conclude a secret is wrong.

The api_key is user- and company-specific and is generated inside the Procountor UI — if Procountor's M2M flow applies to your integration, the API key your customer creates and hands back to you (see the third prerequisite in the connection guide) is that api_key value.

Procountor describes API keys as "credentials bound to a specific user, company and client application". The token you configure below is set once for the whole connector, so plan on one connector configuration serving one Procountor company — a second company means a second API key, a second token, and a separate configuration to hold it.

Saving the token in Apideck

Open the Procountor connector settings in the Apideck Dashboard, enter the access token, and click Save settings.

The connector authenticates with the access token itself: it is the token that belongs in the credential field — never the client ID and never the client secret. Those two stay in your own backend, where they are exchanged for fresh tokens.

Credentials are stored encrypted and masked once saved, so keep your own copy.

Configure this once, at integration level. It applies to every consumer connection on the connector. Your consumers enter no credentials of their own in Vault; the only thing they may hand you is the Procountor API key described above (see the connection guide).

While you are validating, configure the credentials for your testing environment here, and swap them for production credentials in step 5.

Keeping the token current

Procountor documents the access token as "valid for one hour after which you need to perform the authentication again". The connector stores the token you saved and does not renew it. Read those two facts together: the token you paste into the Dashboard stops working roughly an hour after Procountor issued it, and from that point every call through the connector fails with a 401 until the token is replaced.

There is no refresh option to switch on, and no way to make the stored token outlive its hour. Keeping the connector working means repeating two steps on a cycle shorter than that hour:

Re-run the client_credentials exchange above to obtain a fresh access token.
Save that new token as the connector's credential, replacing the previous one.

Step 1 is your own backend's work and is straightforward to schedule. Step 2 is programmatic: Vault's connection update endpoint (PATCH /vault/connections/accounting/procountor-fi, the connectionsUpdate operation) accepts updated connection settings, so the same scheduled job that obtains a fresh token can save it in the next call. An hourly manual paste is not a setup you can run in production — automate both steps together.

4. Build and validate against the Public Testing Server

The testing server runs the same software platform as production, but it cannot enact real financial transactions. Procountor documents these differences on General information:

Works in testing	Does not work in testing
Reading and writing accounting records through the API	Banking — "The testing environment does not execute actual financial transactions nor does it receive statements from banks."
The Procountor UI, for setting up test data	Mail — "The testing server does not send out any mail, electronic or otherwise."
The same software platform as production, for building and validating your integration	Changing or resetting passwords without logging in to the Procountor UI

The same page notes that no sensitive or customer-specific information should be entered into the test environment.

The Apideck connector declares the testing server as https://api-test.procountor.com and production as https://api.procountor.com. Procountor documents its testing-server hosts on General information — if the address in the credentials Procountor issues you differs from the one above, use the address Procountor gave you and report the mismatch to Apideck Support so the declared address can be checked against it.

Get your integration working end to end here, with the testing credentials saved in step 3, before asking Procountor for production access.

5. Move to production

Production is a credential swap, not a toggle:

Ask your Procountor contact for production access once your integration is validated on the testing server.
Exchange your production credentials for a production access token, posting to the production token endpoint in step 3, and replace the testing token in the Apideck Dashboard with the result.
Nothing else changes: the connector calls https://api.procountor.com — the first server in its spec — by default, and the only override is the integration-level server_url setting (which is how a testing-server setup is wired when one has been arranged). With a production token saved and no server_url override, your integration is on production.

Testing credentials do not authenticate against production, and production credentials do not authenticate against the testing server. Procountor is explicit that "the production user accounts are not available on the testing server or vice versa". If you want to keep a working test setup after going live, plan for two separate Apideck environments rather than swapping the same one back and forth.

Because the API key behind your token is bound to a Procountor user and company, going live also means your customer creating a new API client key in their production environment — their testing-environment key does not carry over. Tell them to expect that ask (see the connection guide).

6. Optional — API certification

Procountor also runs an API certification process as the route into its Software Partner Programme — see API certification for the entry bar and review checkpoints.

Troubleshooting

Every API call returns 401, including ones that worked an hour ago. Almost always the access token expired — Procountor's access tokens are valid for one hour, and the connector does not renew them, so a stale token in the Dashboard fails every call. Re-run the token exchange and save the new token (see Keeping the token current in step 3). The other common cause is an environment mismatch: testing credentials pointed at the production server, or the reverse. Confirm which environment the token in the Apideck Dashboard belongs to before escalating.

Your token request itself is rejected. Check that the token endpoint host matches the credentials you are sending — the testing host for testing credentials, https://api.procountor.com for production ones — and that the api_key you are including was created for the same company and user your integration is meant to act as.

You submitted the integrations form and heard nothing back. Credentials are issued by a human team, not a portal. Follow up by email at the integrations-team address on the integrations page, and separately submit the testing environment request — the two requests are handled through different forms and one does not imply the other.

You want to try the connector before requesting credentials. Not possible for this connector: Apideck holds no shared Procountor credentials, so a working connection needs credentials Procountor issued to you.

Some resources return data and others come back empty. Check the Procountor rights of the user whose API key is behind your token before assuming a connector fault — visibility of accounting data in Procountor follows that user's rights, and the API key is user- and company-specific.

For anything on the Apideck side, contact Apideck Support.

Reference

Procountor integrations and API — contact form for integration credentials
Procountor developer documentation — the API documentation hub
M2M authentication — client ID/secret, API keys, and the token exchange
Request Testing Environment — developer registration and test credentials
General information — server addresses, versioning, testing vs production behaviour
API certification — the checkpoints and the Partner Programme prerequisite