Support

Three routes, depending on what you need. Most questions are answered faster by the documentation than by us — but when they're not, customers with a support contract get a tracked ticket and a response time.

Start here

Documentation, video walkthroughs, and troubleshooting articles. The answer to most "why is it doing that" questions is already written down.

Service desk

Support contract required

Report an incident or ask a question and get a tracked ticket with a response time. Runs on Jira Service Management, so you see status, history, and every update in one place.

No account yet? Your administrator can invite you, or ask us.

Is it just you?

Before raising a ticket, check whether we already know. The status page shows every component, including the identity providers and delivery channels that aren't ours.

Severity levels and response times

Pick the severity honestly — it decides the queue, and marking everything critical only slows down the things that really are.

SeverityWhat it meansFirst response
Critical
Signing is not possible at all

Nobody can sign, the service is unreachable, or documents are being lost. Production is stopped.

[TO BE ADDED]
High
A signing route is broken

One method or channel fails — bank identity, one-time codes, a device type — while others still work. A workaround exists but isn't acceptable long term.

[TO BE ADDED]
Normal
Something behaves incorrectly

A defect with a workaround, an integration question, unexpected output on specific documents.

[TO BE ADDED]
Low
Question or request

How-to questions, configuration advice, feature requests, documentation gaps.

[TO BE ADDED]

Response time is not resolution time. First response means a human has read the ticket, confirmed the severity, and told you what happens next. Actual response and resolution commitments are part of your support contract.

Make it faster

What to put in a ticket

Almost every slow ticket is slow because of a missing detail and a round trip to ask for it. These six lines usually remove that round trip entirely.

  • Document or contract token — the fastest way for us to find the exact case. Never send the document itself unless we ask.
  • When it happened — with a timezone. "This morning" costs us an hour of log searching.
  • Signing method and device — pad model, browser, operating system, or whether it was a virtualized desktop.
  • The exact result string or error code — not a paraphrase. Many endpoints return HTTP 200 with the real outcome in a result field.
  • Once or always? — One signer or everyone, one document type or all of them.
  • On-premises: version and relevant log excerpt — the Signosoft release, and the lines around the failure from catalina.out.

Do not paste personal data into a ticket. Send the token, not the contract, and not the signer's identity document. If we need the document, we'll ask through a channel appropriate for it.

A ticket we can act on
Severity: High
Summary:  Bank iD signing fails for one bank since 09:10

Token:    9f3c…a71  (one of ~40 affected)
When:     30 Jul 2026, from 09:10 CEST, still failing
Method:   Bank iD Sign, remote signers, Chrome 141 / Windows
Result:   HTTP 200, body { "result": "ERROR",
          "message": "authorisation rejected" }
Scope:    only signers choosing one specific bank;
          other banks and biometric signing unaffected
Impact:   ~40 policies waiting, branch network unaffected

Already checked: status page shows Bank iD operational,
          our own certificate is valid until 2027

Compare with: "Bank iD doesn't work, please fix." Both get answered — one of them gets answered once.

Without a support contract

The documentation, video tutorials, release notes, and status page are open to everyone, and the developer channel answers integration questions. Tracked incident handling with response times requires a support contract — ask about adding one.

What support covers

  • Defects in the product and in the signing applications
  • Configuration questions, including on-premises deployments
  • Integration questions about the API and the SDK
  • Supported signature pads and devices
  • Upgrades and migration between versions

What it does not

Being straight about this saves everyone a disappointed ticket:

  • Legal advice on whether a given signature level satisfies an obligation in your jurisdiction — that's a question for your own counsel.
  • Faults inside third-party services: a bank's identity provider, your SMTP relay, your certificate authority. We'll help you identify where the fault sits.
  • Development of custom plugins or bespoke integration code, unless that's part of a separate agreement.
  • Your own infrastructure in an on-premises deployment — network, database, container. We support the application running on it.
Contact

Not a support question?

Commercial questions, adding a support contract, security questionnaires, and partnerships go to the team rather than to the service desk.

Security disclosure? Write to the address on the Trust & Security page rather than filing a public ticket.