Support
Where to write about an integration, what to include, and the delay we commit to.
Integration questions go to [email protected]. One address, read by the people who maintain the API — not a general inbox that forwards.
We answer within two business days. That is a ceiling, not an average, and it is what we can hold without an on-call rotation. Mail sent on a Friday evening is answered by Tuesday at the latest.
What to put in the first message
A report that carries these four lines is usually answered once instead of three times:
| Include | Where to find it |
|---|---|
| The request identifier | instance in the Problem Details body of the failing response |
| The operation | operationId from the reference page you called, or the capabilityId you invoked |
| Time, in UTC | The moment of the call, with its timezone — ours are logged in UTC |
| The refusal itself | The HTTP status and the type of the problem document |
Never send an API key, an access token or a refresh token — not even redacted. We never need one to reproduce a refusal, and an address that has received a credential has to be treated as a leak.
Where else to go
| Subject | Channel |
|---|---|
| A vulnerability | [email protected], under our disclosure policy — acknowledged within two business days |
| An outage in progress | status.digitalyser.io, which carries the incident and its timeline before any mail we could send |
| A quota that is too tight, or a plan change | Your organisation's subscription page in the product — a quota is a commercial boundary, not a bug |
| A breaking change you want warned about | The changelog feed, and versioning for what we consider breaking |
What we do not promise
No 24/7 line, no phone escalation, no service credits. Two business days on a European calendar is the whole commitment — announcing an hour and missing it would be worth less to your planning than a delay we actually hold.