Everything in Visena.
One API away.

What our partners build

Your software, Visena underneath

Whatever your firm runs on Visena, the Partner API makes it programmable. Four patterns cover most of what partners ask us for.

Making requests → Lists, paging and sync →

See it in action

Real calls, not slideware

Plain HTTPS and JSON, standard OAuth 2.0 — if your team can call a REST API, they can build on Visena. Every call has the same shape: the instance name, the API version, a locale, then the resource. Here is what the everyday moves look like.

Create records at scale

Probe for duplicates first, then create. Companies with a known organisation number are protected — the API refuses to create the same company twice, a bad reference writes nothing at all, and every imported record shows who loaded it.

# any duplicates before we create?
GET /acme/api/v1/en/company/duplicates?orgNumber=983163327

# clear — create the client company
POST /acme/api/v1/en/company
{ "name": "Fjellheim Regnskap AS",
  "orgNumber": "983163327" }

→ 201 Created · Location: …/company/bQ4wR8

Walk the whole dataset

Cursor paging is built for one consistent extract: start at the first page, follow links.next to the end, and the dataset is yours in a single pass, filtered to exactly the slice you need. It is not a substrate for resuming a sync — an id is allocated at first write rather than at commit, so a row committed out of id order can land behind a walk that has already passed it. Resuming is what the time-windowed timeline is for: cursor-paginated as well, and at-least-once, so de-duplicate by id. Neither list mode reports deletions — for the archive, document/changes is the only read path where a deletion is observable.

GET /acme/api/v1/en/person/cursor?limit=100

{ "items": [ …100 people… ],
  "links": { "next": "…/person/cursor?cursor=eyJp…" } }

# follow links.next until it disappears — export complete

Only what changed

Every resource exposes a change feed: everything created or modified since a timestamp you choose. One watermark, one call — no full re-reads and no diffing on your side, whether you run it every five minutes or once a night.

# everything that changed since last night's run
GET /acme/api/v1/en/person/timeline?since=2026-08-20T02:00:00Z

{ "items": [ …created & modified people… ],
  "links": { "next": "…" } }

# apply, store the new watermark, done

The archive, programmable

Upload files against the client or engagement they belong to, organise them in folders, and pull whole folder trees back as zip bundles. Real binaries go in and out, not just metadata, and a conflict policy decides whether an existing file is replaced, skipped or kept alongside the new one.

# file the signed engagement letter on the client
POST /acme/api/v1/en/document   (multipart)
  file=@engagement-letter.pdf
  entityType=COMPANY  entityId=bQ4wR8

→ 201 Created · Location: …/document/dN3pT7

# later: the whole folder tree as one zip
GET /acme/api/v1/en/document/folder/fR2kX9/content

Precise edits from your front end

Merge-patch updates change exactly the fields you send and nothing else — ideal behind a form in your own portal. Acting for a named user? The response records both identities: the person the change was made for, and what made it.

PATCH /acme/api/v1/en/person/xK9mQ2
Content-Type: application/merge-patch+json

{ "jobTitle": "Head of Operations",
  "directPhone": null }          ← cleared; the rest untouched

→ 200 OK · modified + modifiedBy recorded

Why audit firms in particular

Accountability isn't a feature we added. It's how the API is built.

Your business is trust and traceability. An integration surface that blurs who did what would be disqualifying — so ours never does.

• ✓Every write has a name on it. API changes are attributed to a real person in your instance — the credential's owner — exactly like changes made in Visena itself. Machine activity is never anonymous.
• ✓Acting for someone is recorded as such. On-behalf credentials let a system act for a named employee, and every change records both the person it acted for and the actor behind it. Two identities, one audit trail.
• ✓Destructive actions need explicit intent. Deletes that would cascade are refused until they are acknowledged in the request. Duplicate organisation numbers are blocked outright. The API makes the careless thing hard.
• ✓GDPR tooling included. Compliant person-erasure endpoints and planned-deletion dates are part of the API — privacy obligations handled through the same interface as everything else.
• ✓Strict tenant isolation. Credentials and tokens are bound to one instance. Your data sits behind a wall, not a folder — a token for one customer cannot touch another, ever.
• ✓No lock-in, in writing. Full export is a documented, supported, first-class capability. We keep customers by being good, not by holding data hostage.

Security, without ceremony

Locked down by default, open on your terms

The security model is the same one we trust with our own platform — and it stays out of your developers' way.

• ✓Short-lived, scoped tokens. Access tokens expire on their own, and a scope is mandatory at issuance: a token request that omits scope= is refused with invalid_scope. The read/write split is then enforced per request, in a filter ahead of the endpoint — a read-only export job is unable to write at all.
• ✓Secrets shown once, stored never. Credential secrets are displayed a single time and kept only as a one-way hash. Not even Visena can read them back.
• ✓Revocation in under a minute. Revoke a credential and every token it ever minted stops working within about sixty seconds. Offboarding a vendor is one call.

Professional by design

Standards your engineers already know

No proprietary SDK, no exotic protocol. The Partner API is built on the open standards every integration team speaks — which is why first calls happen in an afternoon, not a sprint.

Machine-readable errors, navigable pagination links, precise partial updates — the conventions are boring on purpose. Boring is what integrates well, and what still integrates well five years from now.

Getting started

From first conversation to production

No procurement maze, no six-week enablement program. This is the whole journey.

• 1Talk to us. Tell us what you want to build — write to sales@visena.com. We walk you through the API and agree the access your integration needs.
• 2Get your credential. Created in minutes inside the Visena instance — a labelled clientId and secret pair, revocable at any time.
• 3Make your first call. One OAuth 2.0 token request, then plain REST. The getting-started guide has your team's first request working the same afternoon.
• 4Go live, stay supported. Roll out with scoped tokens and a rehearsed rotation path — the go-live checklist walks the last mile — and a named Visena contact when you need one.

The guides below cover credentials, tokens, scopes, paging and error handling, and the reference documents every endpoint. Your engineers will feel at home in the first hour.

Questions we hear first

The short answers

Do we need an SDK or special tooling?

No. The API is plain HTTPS with JSON bodies and standard OAuth 2.0. Any language, any HTTP client, any integration platform that can send a request works — most teams make their first call with nothing but curl.

Can we get our data out again?

Yes — completely, and without asking us. Cursor paging walks an entire dataset in one pass, timeline resumes the sync afterwards, and documents download as files or whole folder trees. Exit is a supported feature, not a negotiation.

Does API activity bypass Visena's business rules?

Never. API writes run through the same validation and business logic as Visena's own screens, and land with the same attribution. What is invalid in the interface is invalid through the API — your data stays consistent no matter which door it came through.

Who controls access, and how fast can it be cut?

The customer does. Credentials are created inside their Visena instance, scoped to exactly the permissions the integration needs, and revocable in one call — every token dies within about a minute. Secrets are shown once and stored only as a one-way hash.

Can an integration act on behalf of a specific employee?

Yes. On-behalf credentials are issued by the customer's administrator for a named user. Every change then records both identities — who it was done for, and what did it — which is exactly the trail an audit methodology expects.

What does it cost?

That depends on what you are building and the scale you are planning for. Talk to your Visena contact, or write to sales@visena.com, and we will put together terms that fit.