Server integrations

A server cannot perform the consent step itself. Unattended access therefore always starts from a Jolv account of the organisation, whose profile bounds what the integration can read.

#Recommended setup

1. Create an integration account

   Ask a Jolv administrator of the organisation to invite a dedicated account (for example integration@your-firm.com). Accounts are created by invitation only. Give it the viewer role and only the funds the integration needs. The account's rights are the integration's rights.

2. Authorise once

   A person signs in with that account and completes the interactive authorisation from the integration's OAuth client. Keep the tokens the client receives in your secret store.

3. Renew without a person

   If the authorisation server issued a refresh token alongside the access token, the integration renews its access token at the token endpoint without any further consent. Access stops as soon as the authorisation is revoked or the account is suspended.

#Organisation API keys

API keys bound to an organisation are not available yet. When they ship, each key will be attached to a Jolv user whose profile bounds the key's scope, exactly like the setup above: there will never be a key that reads more than a user can see.

#Good practice

• One integration account per external system, named after it, so the audit log tells who read what.
• Use updated_since on list_campaigns, list_documents, get_operations, get_financial_alerts and get_activity_log to synchronise incrementally.
• Expect 429 with a Retry-After header on bursts, and back off accordingly.
• Never log access tokens. The API never logs request parameters or response data either.