Sevdesk API Integration
Sevdesk is a cloud accounting platform for small businesses, freelancers and their tax advisors in Germany, Austria and Switzerland. It covers invoicing, expenses, contacts and GoBD-compliant bookkeeping. Connect it through Maesn and you reach it with the same REST API and the same data model as every other supported system.
A sevdesk integration in days
Sevdesk is one of the shorter integrations in the catalogue, and what it asks of you is three decisions rather than a long build. Here is what they are, and what Maesn takes off the table.
Collected wherever it fits you
Sevdesk authenticates with an API key that only an administrator can retrieve. Your customer can paste it into a page we host, or into a form inside your own product: you send us the key, and we send back the account key that identifies that connection in every later request.
The same pull as everywhere else
Nothing in a sevdesk account will call your endpoint, so detecting change is a scheduled read. You still decide how often it runs, but you do not write it again for sevdesk: the filter and the pagination are the ones you already use for every other system.
We are on the other side already
Sevdesk asks for no approval and no registration before you build. You register for the technology partner programme once your integration has onboarded its first ten users, and Maesn walks that step with you as an existing partner.
What reaches your code is a REST call and an account key. Teams go live in days, and the system after sevdesk is a configuration step rather than a second project.
A short call is usually enough to tell whether Maesn fits your use case.
HubSpot reaches sevdesk, Lexware and DATEV through one API
HubSpot syncs customer data, invoices and payment reminders into sevdesk, Lexware, DATEV and more, for hundreds of their customers in the DACH region, without building or maintaining a single one of those integrations in-house.
“We integrate German accounting systems and rely on Maesn as a trusted enabler - ensuring seamless data flow, full compliance, stronger partnerships, and efficient, reliable financial processes that support our growth.”
Three reasons to reach the sevdesk API through Maesn
Connecting sevdesk directly is a short project. Keeping it fresh without a single event to build on, and then adding the next system, is the part that decides your roadmap.
The sevdesk work stays here
Collecting the API key, keeping the connection alive and replacing the events sevdesk does not send are what every sevdesk integration has to solve. They are solved once, here, for every customer you connect.
The write side is real, not a read-only mirror
Invoices, customers, suppliers, payments and bank data go into sevdesk through the same interface you read them with, and customers and suppliers update in place. What your use case needs beyond that is a request rather than a rebuild.
The next system costs nothing
Once sevdesk runs, every other supported accounting and ERP system answers on the same interface. Your second integration is a configuration step.
A sevdesk partner programme that asks for nothing up front
Most providers stop at the API. Maesn does the technical enablement and the relationship, and on sevdesk the relationship is unusually cheap to enter: the documentation states outright that there is no approval process and no registration, and nothing you can build changes on the day you join.
Technical enablement
One integration against the Unified API and one data model, identical to every other system Maesn supports. Your engineers meet the same interface here as they will for the next system.
Partnership support
Maesn is an official sevdesk Technology Partner and takes you through the programme when your integration is ready for it, rather than as a gate you clear first.
Nothing to clear up front
There is no approval process and no registration before you start. Anyone can build a sevdesk integration and become a technology partner afterwards.
The threshold is ten onboarded users
You register for the programme once your integration has onboarded its first ten users, so the milestone follows traction rather than preceding it.
The requirements are German only
Sevdesk publishes the partner requirements in German and only in German, which is worth knowing if the team that owns partnerships does not work in it.
The integration runs under your product's name, and the partner status is yours rather than ours. Maesn is the layer behind it.
Maesn is already a sevdesk Technology Partner and runs your step of it with you.
One sevdesk key from your customer, collected on your terms
Sevdesk authenticates with an API key rather than a redirect, which makes it one of the quickest connections in the catalogue and moves the only real question to the user experience: your customer has to fetch a key and hand it over, and where that happens is up to you.
- API key
- Retrieved by your customer
One key in, one account key out. Where your customer enters it is your decision, not sevdesk's.
- The Maesn page
- Your customer pastes the key into maesn Connect and gets a confirmation when it validates. Nothing to build, and the page can be styled with your colours and your logo.
- The headless route
- You post the key to the create-account endpoint from your own form and the account key comes back in the response, so no page outside your product is involved. Available for seven systems, and sevdesk is one of them.
The hosted page is brandable rather than generic: background, button, text, input and error colours plus your SVG logo are configured on our side, so a customer who never leaves your flow does not land on something that looks like a third party.
- 1
Your customer retrieves the key
They log in to sevdesk and copy the API key from their account. It needs administrator rights. Say that in your own interface, because it is the one step you cannot do for them.
- 2
The key reaches Maesn
Either through the hosted page or through your own form and the create-account endpoint. Both paths end in the same place, and the key is stored with the connection rather than travelling with your requests.
- 3
You work with one account key
Maesn stores the connection and returns an account key. From there every request carries your API key plus that account key, the same two headers you already send for every other system in the catalogue.
Every system in the catalogue authenticates differently, and sevdesk is the case where the credential is trivial and the question is where your customer meets it. Unified authentication is what makes that a choice rather than a constraint: the hosted page, the headless endpoint and the way the account key is handed back to you are all configurable there, and identical no matter which system a customer connects.
Sevdesk pushes nothing, so you pull
Sevdesk publishes no webhooks. No object in the coverage matrix carries one, and the documentation has no webhook section, so nothing inside a customer's account will ever call your endpoint.
Nothing. There is no native event on any object, so a change in a customer's account stays invisible until something goes and reads it.
One scheduled read, with the same filter and the same pagination you use for every other system. The code that detects change on sevdesk is the code you already wrote, pointed at a different account key.
Because the detection is a read rather than a push, how fresh your data is depends on how often you run it. Polling has one advantage that is easy to overlook: if your service is down for an hour, the next read still returns everything that changed in the meantime. An event fired during that hour would have been missed.
A system without events is where the cost of a per-system integration shows up most plainly: you write a change-detection loop for sevdesk, and then another one for the next system with its own filter syntax and its own idea of what a page is. One way to filter and page removes that repetition, so the delta pull you build here keeps working against a system that does push events. Systems that announce their own changes and systems you have to ask reach you on two paths of the same interface: the event model and the scheduled read. Sevdesk offers only the second one today, so the day you add a system that does push, your code does not change.
What sevdesk asks for up front
The prerequisite list in sevdesk's own documentation is one line long: an account with administrator rights. Four things are worth planning for anyway.
- A sevdesk account with administrator rights
- Your customer's account, not yours. The API key is only retrievable by an administrator, from inside sevdesk itself.
- A decision on where the key is entered
- Maesn's own page is the default and needs nothing from you. The headless route lets you build the form yourself and post the key to the create-account endpoint, which returns the account key straight away and keeps the whole step inside your product.
- A schedule, because nothing will call you
- There is no native event on any sevdesk object. Change detection is a read you run on an interval, so the interval is a product decision worth making before the build rather than after the first complaint.
- Nothing at all from the partner programme, yet
- No approval, no registration, no fee before you start. The technology partner step comes after your first ten onboarded users, and the requirements are published in German only.
We walk through the key collection and the partner step with you.
One shape for sevdesk, and for the system after it
Sevdesk is invoicing and bookkeeping for small companies, with the strengths and the edges that follow from it. A shared shape is what keeps both out of the code you write.
Payments can be written, not read
You can post a payment to sevdesk and there is no way to read one back: the matrix carries create for payments and no read at all. If your product reconciles rather than only records, that is the line to check before anything else.
Customers and suppliers update in place
Those two take a change to an existing record directly. Everywhere else a correction is written as a new document, which is what accounting practice expects anyway. The object and operation combinations that are not switched on by default are available on request rather than unavailable, so tell us which ones your use case needs.
No object deletes by default
No object has delete enabled. Accounting practice expects corrections and cancellations as new documents anyway, so plan them that way rather than around a delete you would have to request.
Whatever you read comes back in the shared common data model, so an invoice from sevdesk has the same shape as an invoice from a system ten times its size, and the code you write here is the code you reuse for the next one.
That matters most where a product outgrows one vendor. Sevdesk covers invoicing, expenses and GoBD-compliant bookkeeping, which is what its customers run their business on. The ledger side that a larger finance stack expects, journals and a trial balance among it, lives in other systems, and those are reachable on the same interface without a second integration. Building against the model rather than against one vendor is what makes that a configuration step instead of a project.
Tell us which objects your use case needs and we will confirm what is possible.
