Weclapp API Integration
Weclapp is a cloud ERP used by small and mid-sized companies in Germany and the wider German-speaking market, and beyond it in the Netherlands, France, Italy, Spain, Poland and the UK. One platform carries CRM, accounting, inventory, projects and the commerce connections around them, which is why an integration against it rarely stops at invoices.
Three Weclapp quirks that never reach your codebase
Three things about Weclapp cost a team its first week, and none of them is the REST call itself. Maesn absorbs all three before you write a line of code.
Collected once, injected on every call
Weclapp gives each customer their own subdomain, and the tenant id belongs in the path of every request rather than in a header you can set globally. Maesn collects it alongside the API token when your customer connects and routes every later call for you.
One shape, whatever the JSON said
Weclapp serialises prices and quantities as strings to protect precision, sends timestamps as milliseconds since 1970 and reads an empty string as null. Maesn normalises all three, so an amount is a decimal and a date is a date before it reaches you.
Fifteen of them, created and removed for you
A Weclapp subscription is created per connected customer rather than per app, so one customer who wants everything is fifteen subscriptions, and fifteen deletions when they leave. Maesn opens and closes them and hands you the same event shape as every other system.
What is left on your side is one REST call against a data model you implement once. Teams go live in days rather than spending a quarter learning one vendor.
A short call is usually enough to tell whether Maesn fits your use case.
Paywise replaced manual invoice imports with integrations
Paywise recovers unpaid invoices for businesses, from the first reminder through to legal enforcement. Their customers used to upload those invoices by hand, and the overdue list now comes out of whichever accounting system each of them already runs.
“Our customers can connect their existing tools instantly, which drives engagement and makes Maesn a key part of our success strategy.”
Three reasons to reach the Weclapp API through Maesn
Connecting Weclapp directly is a project you can finish. Owning it, and then the next system, is the part that decides your roadmap.
Changes arrive instead of being fetched
Five weclapp resources reach you as events through Maesn: customers, suppliers, invoices, credit notes and sales orders. Maesn registers the subscription per connected customer and hands you the same event shape you already handle, so this system costs you no new polling loop.
One connection, both directions
Reading and writing travel on the same connected customer, so a product that reads a supplier and posts an invoice back needs one authorisation from them and not two.
The next system costs nothing
Once Weclapp runs, every other supported accounting and ERP system answers on the same interface. Your second integration is a configuration step.
The Weclapp API needs two values
Weclapp authenticates with an API token the customer generates in their own account. What comes with it is the id of their Weclapp instance, a second value the API requires on every call rather than only at connection time. There are two ways to collect the pair.
- API token
- Every connection
- Maesn Connect
- A branded popup in your own look and feel with a field for the token and one for the tenant id. You can pass the tenant id as a query parameter to pre-fill it, which the documentation offers for Weclapp and one other system.
- Headless
- Build the input yourself and submit both values through the create account endpoint. No Maesn interface appears at all, and the account key comes back in the response.
The tenant id is why this matters beyond the first call. It belongs in the path of every Weclapp request rather than in a header, so without it every route in your code would have to know which customer it is building a URL for.
- 1
Your customer generates the token
An administrator opens the settings of their own Weclapp instance and creates a token in the API token section. The URL they do it at already carries their tenant id, which is the second value you need.
- 2
Token and tenant id reach Maesn
Through Maesn Connect or through the headless endpoint, whichever you chose. Both values are validated on submit, so a wrong token or a mistyped instance id fails there rather than later in production.
- 3
You work with one account key
Maesn stores the pair 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.
A second required value is not unusual on its own. What makes it structural here is where Weclapp expects it: in the path of the request rather than in a header, so it is not something you set once on an HTTP client and forget. Unified authentication is what turns that into a one-time cost. The token, the tenant id and the account key behave here exactly as an OAuth consent screen and a refresh cycle behave on the next system, so the second integration inherits the work instead of repeating it with different vocabulary.
Weclapp events need a named pair
Weclapp supports native webhooks, and five of its resources are wired through Maesn today, so changes there reach you as events rather than through polling. Maesn creates the subscriptions per connected customer and normalises what arrives, so the shape you handle is identical to every other system you integrate.
Weclapp wants a pair, so a subscription covers one resource and one event type rather than a resource and everything that happens to it.
What an event carries is worth knowing before you build on it. Weclapp fills the event type, the resource and the id of the record that changed, which is enough to fetch it. The two fields some systems add, a change timestamp and the user behind the change, stay empty here. The envelope is the same everywhere, what a system puts in it is not.
Where a subscription lives is the part that decides how much of this you end up owning. On Xero the resources are chosen once inside the app and every customer’s events arrive at one endpoint you then have to route. On Weclapp a subscription belongs to one connected customer, which keeps them cleanly separated and means there is one to create, watch and remove per customer per pair. Maesn runs that side and emits one event model regardless of which shape the system underneath uses.
Bills and Payments read fine and announce nothing, so a product that watches supplier invoices or incoming payments asks Weclapp on a schedule. One way to filter and page is what keeps that from becoming a second implementation: the change-detection loop you write for those two is the same loop you already run against systems that push nothing at all.
What Weclapp asks for up front
Weclapp puts four things in front of an integration. Three are quick to arrange, and the fourth is worth knowing before it goes into a roadmap.
- An account with administrator permissions
- The API token is generated inside Weclapp, in the API token section of the account settings, so the connecting user needs administrator rights. Each of your customers does this once for their own environment.
- The tenant id belongs to the credentials
- Weclapp needs two values rather than one: the API token and the id of the customer's own instance, which also appears in the URL they generate the token from. Both are required, and Maesn stores them together.
- The rate limit is enforced without being published
- Weclapp applies a limit and does not state the value, which makes it something to design for rather than something to calculate. Maesn queues and paces requests against it so a burst on your side does not become a failed sync on theirs.
- The Weclapp Store is not taking new plugins right now
- Weclapp distributes plugins through its own store, and listing is currently open to its sales partners only while the programme is rebuilt. That does not touch the integration, which your customers connect themselves, but it does mean the store is not a distribution plan you can date yet.
We walk through the token, the tenant id and the sandbox with you.
One party endpoint, two objects you already use
Weclapp v2 publishes a single party collection where most systems publish customers and suppliers separately. What reaches your code is the shape you already handle everywhere else.
Reads run wider than writes
Seven objects read, three create and two update, and no object has delete enabled. Customers and suppliers are the only two you can edit in place, so a product that corrects records rather than posting new ones should check that against its use case early. Accounting practice expects corrections as new documents anyway.
Two readable objects stay quiet
Every object that sends an event can also be read, so nothing here notifies you about a record you cannot fetch. It does not run the other way: bills and payments are readable and send nothing today, so the purchase side and the money side are polled unless you ask for their events.
Anything else is a request, not a dead end
Objects marked on demand are not missing, they are simply not enabled by default. Twenty of the thirty-seven sit there, including the accounts, journals, transactions and open items a ledger use case starts from. Tell us which ones you need and they get added.
Weclapp v2 publishes a single party collection, with a type field telling the kinds of business partner apart. Everything you read comes back in the shared common data model instead, so a Weclapp customer has the same shape as a customer from a system that never merged the two, and the resolution happens underneath your code rather than inside it.
What that shape covers today is the document trail: the two parties plus the bills, invoices, credit notes, payments and sales orders that pass between them. The ledger underneath sits one step away rather than outside, with accounts, journals, open items and transactions all reachable on request. For a product that reads what a customer has invoiced and been billed, the document trail is the whole surface. For one that starts at the ledger, it is a conversation about which objects to switch on, and it is worth having before the design is fixed.
Tell us which objects your use case needs and we will confirm what is possible.
