Weclapp-Schnittstelle und API-Integration
Weclapp ist ein Cloud-ERP, das kleine und mittlere Unternehmen in Deutschland und im weiteren deutschsprachigen Raum einsetzen, und darüber hinaus in den Niederlanden, Frankreich, Italien, Spanien, Polen und UK. Eine Plattform trägt CRM, Buchhaltung, Lager, Projekte und die Commerce-Anbindungen darum herum, und deshalb hört eine Integration dagegen selten bei den Rechnungen auf.
Drei Weclapp-Eigenheiten, die nie in Ihrem Code ankommen
Drei Dinge an Weclapp kosten ein Team seine erste Woche, und keines davon ist der REST-Aufruf selbst. Maesn fängt alle drei ab, bevor Sie eine Zeile Code schreiben.
Einmal eingesammelt, bei jedem Aufruf eingesetzt
Weclapp gibt jedem Kunden eine eigene Subdomain, und die Tenant-ID gehört in den Pfad jeder Anfrage und nicht in einen Header, den man global setzen kann. Maesn sammelt sie zusammen mit dem API-Token ein, wenn Ihr Kunde sich verbindet, und leitet jeden späteren Aufruf für Sie.
Eine Form, was immer das JSON sagte
Weclapp gibt Preise und Mengen als Zeichenketten aus, um die Genauigkeit zu wahren, sendet Zeitstempel als Millisekunden seit 1970 und liest eine leere Zeichenkette als null. Maesn vereinheitlicht alle drei. Ein Betrag ist also eine Dezimalzahl und ein Datum ein Datum, bevor es bei Ihnen ankommt.
Fünfzehn davon, für Sie angelegt und entfernt
Ein Weclapp-Abonnement wird je angebundenem Kunden angelegt und nicht je App. Ein Kunde, der alles will, sind also fünfzehn Abonnements und fünfzehn Löschungen, wenn er geht. Maesn öffnet und schließt sie und übergibt Ihnen dieselbe Event-Form wie jedes andere System.
Auf Ihrer Seite bleibt ein REST-Aufruf gegen ein Datenmodell, das Sie einmal implementieren. Teams gehen in Tagen live, statt ein Quartal damit zu verbringen, einen Hersteller zu lernen.
Ein kurzes Gespräch genügt meist, um zu klären, ob Maesn zu Ihrem Anwendungsfall passt.
Paywise hat manuelle Rechnungsimporte durch Integrationen ersetzt
Paywise treibt unbezahlte Rechnungen für Unternehmen ein, von der ersten Mahnung bis zur gerichtlichen Durchsetzung. Ihre Kunden haben diese Rechnungen früher von Hand hochgeladen, und die Liste der offenen Posten kommt jetzt aus dem Buchhaltungssystem, das jeder von ihnen ohnehin einsetzt.
“Unsere Kunden können ihre vorhandenen Werkzeuge sofort anbinden. Das erhöht die Nutzung und macht Maesn zu einem festen Bestandteil unserer Erfolgsstrategie.”


Drei Gründe, die Weclapp-Schnittstelle über Maesn anzubinden
Weclapp direkt anzubinden ist ein Projekt, das Sie abschließen können. Es dann zu besitzen, und danach das nächste System, entscheidet über Ihre Roadmap.
Änderungen kommen an, statt geholt zu werden
Fünf Weclapp-Ressourcen erreichen Sie über Maesn als Events: Kunden, Lieferanten, Rechnungen, Gutschriften und Kundenaufträge. Maesn registriert das Abonnement je angebundenem Kunden und übergibt Ihnen dieselbe Event-Form, die Sie ohnehin verarbeiten. Dieses System kostet Sie also keine neue Abfrageschleife.
Eine Verbindung, beide Richtungen
Lesen und Schreiben laufen über denselben angebundenen Kunden. Ein Produkt, das einen Lieferanten liest und eine Rechnung zurückschreibt, braucht von ihm also eine Freigabe und nicht zwei.
Das nächste System kostet nichts
Sobald Weclapp läuft, antwortet jedes andere unterstützte Buchhaltungs- und ERP-System auf derselben Schnittstelle. Ihre zweite Integration ist ein Konfigurationsschritt.
Die Weclapp-API braucht zwei Werte
Weclapp authentifiziert mit einem API-Token, das der Kunde in seinem eigenen Konto erzeugt. Dazu kommt die ID seiner Weclapp-Instanz, ein zweiter Wert, den die API bei jedem Aufruf verlangt und nicht nur beim Verbinden. Es gibt zwei Wege, das Paar einzusammeln.
- API-Token
- Jede Verbindung
- Maesn Connect
- Ein Popup in Ihrem eigenen Erscheinungsbild, mit einem Feld für das Token und einem für die Tenant-ID. Die Tenant-ID können Sie als Query-Parameter übergeben, um sie vorzubelegen, und die Dokumentation bietet das für Weclapp und ein weiteres System an.
- Headless
- Bauen Sie die Eingabe selbst und reichen Sie beide Werte über den Create-Account-Endpunkt ein. Es erscheint gar keine Maesn-Oberfläche, und der Account-Key kommt in der Antwort zurück.
Die Tenant-ID ist der Grund, warum das über den ersten Aufruf hinaus zählt. Sie gehört in den Pfad jeder Weclapp-Anfrage und nicht in einen Header, ohne sie müsste also jede Route in Ihrem Code wissen, für welchen Kunden sie gerade eine URL baut.
- 1
Ihr Kunde erzeugt das Token
Ein Administrator öffnet die Einstellungen seiner eigenen Weclapp-Instanz und erzeugt im Bereich API-Token ein Token. Die URL, auf der er das tut, trägt bereits seine Tenant-ID, und das ist der zweite Wert, den Sie brauchen.
- 2
Token und Tenant-ID erreichen Maesn
Über Maesn Connect oder über den Headless-Endpunkt, je nachdem, was Sie gewählt haben. Beide Werte werden beim Absenden geprüft. Ein falsches Token oder eine vertippte Instanz-ID scheitert also dort und nicht später im Produktivbetrieb.
- 3
Sie arbeiten mit einem Account-Key
Maesn verwahrt das Paar und gibt einen Account-Key zurück. Ab da trägt jede Anfrage Ihren API-Schlüssel und diesen Account-Key, dieselben zwei Header, die Sie für jedes andere System im Katalog ohnehin schon senden.
Ein zweiter Pflichtwert ist für sich genommen nichts Ungewöhnliches. Strukturell wird es hier dadurch, wo Weclapp ihn erwartet: im Pfad der Anfrage und nicht in einem Header, es ist also nichts, was Sie einmal an einem HTTP-Client setzen und dann vergessen. Unified Authentication macht daraus einen einmaligen Aufwand. Das Token, die Tenant-ID und der Account-Key verhalten sich hier genauso wie ein OAuth-Zustimmungsdialog und ein Refresh-Zyklus beim nächsten System, die zweite Integration erbt die Arbeit also, statt sie mit anderem Vokabular zu wiederholen.
Weclapp-Events brauchen ein benanntes Paar
Weclapp unterstützt native Webhooks, und fünf seiner Ressourcen sind heute über Maesn verdrahtet, Änderungen dort erreichen Sie also als Events statt über Abfragen. Maesn legt die Abonnements je angebundenem Kunden an und vereinheitlicht, was ankommt. Die Form, die Sie verarbeiten, ist damit bei jedem System identisch, das Sie anbinden.
Weclapp will ein Paar. Ein Abonnement deckt also eine Ressource und einen Event-Typ ab statt einer Ressource und allem, was mit ihr geschieht.
Was ein Event mitbringt, sollten Sie wissen, bevor Sie darauf bauen. Weclapp füllt den Event-Typ, die Ressource und die ID des Datensatzes, der sich geändert hat, und das genügt, um ihn zu holen. Die zwei Felder, die manche Systeme ergänzen, ein Änderungszeitstempel und der Nutzer hinter der Änderung, bleiben hier leer. Der Umschlag ist überall derselbe, was ein System hineinlegt, nicht.
Wo ein Abonnement liegt, entscheidet darüber, wie viel davon Ihnen am Ende gehört. Bei Xero werden die Ressourcen einmal in der App gewählt, und die Events jedes Kunden kommen an einem Endpunkt an, den Sie danach verteilen müssen. Bei Weclapp gehört ein Abonnement zu einem angebundenen Kunden, das trennt sie sauber und heißt, dass je Kunde und Paar eines anzulegen, zu beobachten und zu entfernen ist. Maesn betreibt diese Seite und gibt ein Event-Modell aus, gleich welche Form das System darunter benutzt.
Eingangsrechnungen und Zahlungen lassen sich gut lesen und melden nichts, ein Produkt, das Lieferantenrechnungen oder eingehende Zahlungen beobachtet, fragt Weclapp also nach Zeitplan. Ein Weg, zu filtern und zu paginieren verhindert, dass daraus eine zweite Implementierung wird: Die Schleife zur Änderungserkennung, die Sie für diese beiden schreiben, ist dieselbe, die Sie schon gegen Systeme fahren, die gar nichts senden.
Was Weclapp vorab verlangt
Weclapp stellt vier Dinge vor eine Integration. Drei sind schnell erledigt, und das vierte sollte man kennen, bevor es in eine Roadmap kommt.
- Ein Konto mit Administratorrechten
- Das API-Token wird in Weclapp erzeugt, im Bereich API-Token der Kontoeinstellungen. Der verbindende Nutzer braucht also Administratorrechte. Jeder Ihrer Kunden macht das einmal für die eigene Umgebung.
- Die Tenant-ID gehört zu den Zugangsdaten
- Weclapp braucht zwei Werte statt einem: das API-Token und die ID der eigenen Instanz des Kunden, die auch in der URL steht, auf der er das Token erzeugt. Beide sind Pflicht, und Maesn verwahrt sie gemeinsam.
- Die Ratenbegrenzung gilt, ohne veröffentlicht zu sein
- Weclapp wendet eine Grenze an und nennt den Wert nicht. Man entwirft also dafür, statt sie auszurechnen. Maesn reiht Anfragen ein und taktet sie dagegen, damit eine Spitze auf Ihrer Seite auf deren Seite kein fehlgeschlagener Abgleich wird.
- Der Weclapp Store nimmt derzeit keine neuen Plugins auf
- Weclapp vertreibt Plugins über einen eigenen Store, und ein Eintrag steht derzeit nur den Vertriebspartnern offen, solange das Programm umgebaut wird. Die Integration berührt das nicht, Ihre Kunden verbinden sie selbst, aber es heißt, dass der Store noch kein Vertriebsplan mit Datum ist.
Wir gehen das Token, die Tenant-ID und die Sandbox mit Ihnen durch.
Ein Party-Endpunkt, zwei Objekte, die Sie schon nutzen
Weclapp v2 veröffentlicht eine einzige Sammlung für Geschäftspartner, wo die meisten Systeme Kunden und Lieferanten getrennt führen. In Ihrem Code kommt die Form an, die Sie überall sonst schon verarbeiten.
Lesezugriffe reichen weiter als Schreibzugriffe
Sieben Objekte lassen sich lesen, drei anlegen und zwei aktualisieren, und für kein Objekt ist das Löschen freigeschaltet. Kunden und Lieferanten sind die einzigen beiden, die Sie an Ort und Stelle bearbeiten können. Ein Produkt, das Datensätze korrigiert statt neue zu buchen, sollte das also früh gegen seinen Anwendungsfall prüfen. Die Buchhaltungspraxis erwartet Korrekturen ohnehin als neue Belege.
Zwei lesbare Objekte bleiben still
Jedes Objekt, das ein Event sendet, lässt sich auch lesen. Nichts benachrichtigt Sie hier also über einen Datensatz, den Sie nicht holen können. Umgekehrt gilt das nicht: Eingangsrechnungen und Zahlungen sind lesbar und senden heute nichts, die Einkaufsseite und die Geldseite werden also abgefragt, solange Sie deren Events nicht anfragen.
Alles andere ist eine Anfrage und keine Sackgasse
Objekte mit der Kennzeichnung auf Anfrage fehlen nicht, sie sind nur nicht standardmäßig freigeschaltet. Zwanzig der siebenunddreißig stehen dort, darunter die Konten, Journale, Buchungen und offenen Posten, mit denen ein Anwendungsfall rund ums Hauptbuch anfängt. Sagen Sie uns, welche Sie brauchen, und sie kommen dazu.
Weclapp v2 veröffentlicht eine einzige Sammlung für Geschäftspartner, mit einem Typfeld, das die Arten von Geschäftspartner auseinanderhält. Alles, was Sie lesen, kommt stattdessen im gemeinsamen Common Data Model zurück, ein Weclapp-Kunde hat also dieselbe Form wie ein Kunde aus einem System, das die beiden nie zusammengelegt hat, und die Auflösung geschieht unter Ihrem Code statt in ihm.
Was diese Form heute abdeckt, ist die Belegspur: die beiden Geschäftspartner plus die Eingangsrechnungen, Rechnungen, Gutschriften, Zahlungen und Aufträge, die zwischen ihnen laufen. Das Hauptbuch darunter liegt einen Schritt entfernt statt außerhalb, mit Konten, Journalen, offenen Posten und Transaktionen, die alle auf Anfrage erreichbar sind. Für ein Produkt, das liest, was ein Kunde fakturiert hat und was ihm berechnet wurde, ist die Belegspur die ganze Oberfläche. Für eines, das beim Hauptbuch anfängt, ist es ein Gespräch darüber, welche Objekte einzuschalten sind, und das führt man besser, bevor der Entwurf feststeht.
Sagen Sie uns, welche Objekte Ihr Anwendungsfall braucht, und wir bestätigen, was möglich ist.











