weclapp Integration Research

Date: 2026-04-14 Status: Research Complete — Some hands-on items deferred (sandbox testing, webhook signature verification)

Table of Contents

1. Summary
2. Capability Matrix
3. System Overview
4. Integration Intermediaries & Middleware
5. Authentication & Connectivity
6. Invoice/Document Submission
7. Master Data Access
8. Historical Bookings / Journal Entries
9. Status & Feedback
10. Unresolved Questions
11. Suggested Hands-On Testing Plan
12. Dead Ends
13. Sources
14. Retractions

Summary

weclapp is a German cloud ERP (SaaS) for small and medium-sized businesses, founded in 2008, based in Marburg/Karlsruhe, certified ISO 27001 and GoBD-conform, with all data hosted in Frankfurt. weclapp SE was acquired by Exact in October 2022. It exposes a comprehensive REST API (v2 is the current major version, v1 still available) covering ~150 resources, including a first-class /purchaseInvoice endpoint suitable for AP automation.

The native API offers two distinct paths for AP invoice submission: (1) structured POST to /purchaseInvoice with full line-item, ledger-account, cost-center, and tax detail; or (2) document upload to /purchaseInvoice/startInvoiceDocumentProcessing/multipartUpload, which routes PDFs/images through Klippa-powered OCR and XML/ZUGFERD/FATTURAPA files through e-invoice detection — both produce a purchase invoice in INVOICE_RECEIVED status. PDF documents can also be attached to a structured invoice after creation via POST /document/upload.

Master data is well-covered natively: /party (suppliers and customers as boolean flags on a unified party entity), /ledgerAccount (full CRUD), /costCenter, /costType, /tax, /termOfPayment, /financialYear. Historical bookings are available via /accountingTransaction (read-only via GET; writeable only via the /accountingTransaction/batchBooking impersonal-booking action), and /purchaseOpenItem gives read access to outstanding payables. Webhooks support created / updated / deleted events on any entity, with a minimal payload {entityId, entityName, type} and a built-in retry ladder (1m → 5m → 30m → 5h → 1d → deactivation).

Maesn provides a weclapp connector but covers a narrower surface than the native API: customers, suppliers, and invoices are fully supported; bills, journal entries, ledger accounts, and purchase orders are flagged as "not supported by weclapp" in the Maesn dev docs (this phrasing is misleading — those resources do exist natively, they are just outside Maesn's connector scope). Make.com has two community apps; the richer "Maxmel Tech" variant exposes purchase invoice and supplier CRUD plus document upload. Zapier, Chift, Celigo, n8n, and Tray.io do not currently ship a weclapp connector.

Capability Matrix

1. System Overview

What is weclapp?

"weclapp is the ERP-platform for teams. Whether CRM, merchandise management or accounting: With weclapp, teams jointly control all important business processes in just one software." — weclapp.com (search summary)

"All data is stored in Germany in accordance with the strict German data protection regulations. […] weclapp is a German company certified according to ISO 27001. weclapp is, among other things, ISO 27001-certified and GoBD-conform." — weclapp.com (search summary)

"In October 2022, weclapp was acquired by Exact, a leading provider of business and accounting software." — Crunchbase / search summary

Confidence: High

• Vendor: weclapp SE (subsidiary of Exact Holding since October 2022)
• Founded: 2008; cloud platform launched 2013
• Type: Cloud-only ERP SaaS (multi-tenant, per-tenant subdomain)
• Headquarters: Marburg, Germany; offices in Karlsruhe, Kitzingen
• Hosting: Frankfurt data center, ISO 27001 certified
• Compliance: GoBD-conform (German tax/audit standard)
• Market: German SMEs, focused on services, trade, manufacturing
• Modules: CRM, ERP (orders/invoicing), accounting, project management, warehouse management, e-commerce connections, helpdesk

API Architecture

• Type: REST, JSON-only request/response
• Versions: v1 and v2 both available; v2 is recommended for new development
• Base URL: https://<TENANT>.weclapp.com/webapp/api/v2/

"The base URL for the API is https://<TENANT>.weclapp.com/webapp/api/v2/ where <TENANT>.weclapp.com is the domain of the specific weclapp instance. So each weclapp instance has its own API endpoints which allow accessing data for that particular instance." — weclapp OpenAPI v2 spec, header description

• Resource pattern (per spec):

• Number serialization: decimals are sent as JSON strings (not numbers) "to prevent accidental loss of precision" (spec)
• Date format: Unix milliseconds since epoch (integer), not ISO 8601
• Compression: required (Accept-Encoding: gzip); the API enforces gzip on responses if the header is missing
• Versioning policy: spec quote: "The existing version remains available for at least one year after the release of a new version."

Available v2 endpoints (count)

The OpenAPI v2 spec is ~46,500 lines and exposes ~150 distinct top-level resources. Functional groups directly relevant to AP automation:

• AP / purchasing: /purchaseInvoice, /purchaseOrder, /purchaseOrderRequest, /purchaseRequisition, /purchaseOpenItem, /incomingGoods, /blanketPurchaseOrder
• Accounting: /accountingTransaction, /ledgerAccount, /costCenter, /costCenterGroup, /costType, /tax, /taxDeterminationRule, /financialYear, /personalAccountingCode, /articleAccountingCode, /bankAccount, /bankTransaction, /cashAccount, /sepaDirectDebitMandate, /paymentRun, /paymentRunItem
• Master data: /party (customers + suppliers), /article, /articleCategory, /currency, /termOfPayment, /paymentMethod, /region, /legalForm
• Operational: /document, /webhook, /customAttributeDefinition, /job/status, /job/abort

2. Integration Intermediaries & Middleware

Maesn (existing Orcha intermediary for DATEV)

"weclapp" appears in Maesn's official integration list alongside DATEV, Xero, sevdesk, Xentral, Microsoft Business Central. — maesn.com/integrations

"Requires weclapp Personal Access Token and Tenant ID" — maesn.mintlify.app/integrations/weclapp

Capability map per Maesn dev docs (mintlify):

"Weclapp webhooks support: CUSTOMER, SUPPLIER, INVOICE, CREDIT_NOTE, SALES_ORDER resources with CREATED, UPDATED, DELETED events" — maesn.mintlify.app/integrations/weclapp

Marketing-page vs dev-docs contradiction: The Maesn marketing page states it supports "invoices, bills, credit notes, customers, suppliers, contacts, payments, journal entries, purchase orders, sales orders, and more" for weclapp (maesn.com/integrations/weclapp), while the developer documentation explicitly marks bills, journal entries, purchase orders, and ledger accounts as not supported or on-demand. The dev docs should be treated as authoritative.

Misleading wording note: Maesn's "Not supported by weclapp" label for purchase orders, journal entries, and ledger accounts is inaccurate as a description of weclapp itself — these resources all exist in the weclapp v2 API (/purchaseOrder, /accountingTransaction, /ledgerAccount). The accurate reading is "not supported by Maesn's weclapp connector."

Make.com (community-maintained, two variants)

"weclapp is a community developed application... Make does not maintain or support this integration." — make.com weclapp app

Maxmel Tech variant (apps.make.com/weclapp-s3mgzy) — modules quoted from Make's app catalog:

• Search/Get: Get a purchase invoice, Get a supplier, Get a party, Get a customer, Get a purchase order, Get a sales invoice, Get a sales order, Get a quotation, Get a ticket
• Create: Contact, Customer, Lead, Party, Purchase Invoice, Purchase Invoice from Purchase Order, Purchase Order, Quotation, Sales Invoice, Sales Invoice from Sales Order, Sales Order, Supplier, Ticket
• Update: Customer, Lead, Party, Purchase Invoice, Purchase Order, Quotation, Sales Invoice, Sales Order, Supplier, Ticket Status
• List: Purchase Invoices, Suppliers, Parties, ...
• Other: Upload Document, Download Latest Sales Invoice PDF, Make an API Request
• Auth: per-user API token

The richer of the two community apps. No ledger accounts, journal entries, or cost centers modules.

#makeitfuture variant (apps.make.com/weclapp-z9gz53-5s74fk) — thinner: only customer/invoice CRUD, no purchase invoices or suppliers.

Workato

"Triggers: New/updated record (real-time), New/updated records (batch). Actions: Create record in weclapp, Get record by ID, Search object, Update object, plus custom actions." — workato.com/integrations/weclapp

Generic record-shape interface — no entity-specific (purchase invoice, supplier, ledger) pre-built operations quoted. Effectively a thin wrapper over the native API.

Intermediaries WITHOUT a weclapp connector

Confidence: High (for absence findings — searched directly on each platform's connector hub)

3. Authentication & Connectivity

Authentication

"You can authorize against the API with an API token. The token is configurable in your weclapp account under My settings > API. […] Authenticating using a token is possible in two ways: the token can be sent using the AuthenticationToken header AuthenticationToken: {api_token} [or] the standard HTTP Basic authentication can be used: the username needs to be "*" and the password is the token" — weclapp OpenAPI v2 spec, header description

"Dein API-Token ist benutzerspezifisch. Du findest ihn über deinen Benutzernamen > Meine Einstellungen." — doc.weclapp.com/knowledgebase/wo-finde-ich-den-weclapp-api-token

"weclapp übergibt über die API nur die Berechtigungen, die der Benutzer des API-Tokens besitzt." — doc.weclapp.com/knowledgebase/gibt-es-eine-api-zu-weclapp

"Du kannst einen API-Token neu erzeugen, wenn du den Eindruck hast, dass ein Unbefugter den Token bekommen hat." — same source

Analysis:

• Tokens are user-scoped, not tenant-scoped or app-scoped. Each user has one API token; deleting/regenerating invalidates the prior one.
• No OAuth flow. Token-based only. This means an Orcha integration must persist a customer-supplied token per tenant; there is no developer/app registration program for delegated auth.
• Permissions inherit from the user whose token is used. Best practice is to create a dedicated "API user" with the minimum required role (e.g., access to purchaseInvoice, party, ledgerAccount, costCenter, webhook).
• No published expiration policy — tokens persist until manually regenerated. (Confidence: Medium — based on absence of evidence in the KB pages read.)

Connectivity

• Base URL pattern: https://<TENANT>.weclapp.com/webapp/api/v2/ — the tenant subdomain is required
• Required headers:
  • Accept: application/json
  • Content-Type: application/json (PUT/POST)
  • Accept-Encoding: gzip
  • User-Agent: ... — spec requests this for client identification
• Compression: mandatory; the API will enforce gzip if not requested
• Error format: RFC 7807 problem+json (in transition — currently served as application/json)

Rate Limits / Load Management

"The weclapp API has no fixed rate limits, and we want to keep it that way. […] There is a limit on the number of parallel requests per tenant. Multiple parallel requests are allowed, even if you exceed the limit. Requests exceeding the limit are not rejected but wait until resources become available. […] The requests can currently wait in the queue for up to 30 seconds, after that the application will respond with a HTTP 429 Too Many Requests response." — OpenAPI v2 spec, header description

"We recommend using request timeouts of at least one minute to avoid aborting requests too early that would get a successful response." — same source

Operational implications:

• No published numeric ceiling. The throttle is dynamic, based on concurrent-request count + total computation time.
• Clients should set >=60s request timeouts.
• Spec recommends: implement HTTP 429 retry with exponential backoff; prefer fewer larger requests (e.g., filter=id in[...]); use webhooks instead of polling; cache rarely-changing data (e.g., custom attribute definitions).

Subscription tier required

ERP Starter (€39/month/user, monthly-only): Contact Management, Quotations & invoices, Tasks & projects, Accounting & banking, Reporting, E-Invoicing. No API-access listed. — weclapp.com/en/pricing

ERP Services (€86 monthly / €95 annual): Starter features plus CRM, Tasks/calendar/campaigns, Offer & order, Project Management, Time tracking, "API-access" — same source

ERP Trade (€163 monthly / €179 annual): Services features plus Merchandise Management, Disposition & purchasing, Warehouse Management, Serial & batch number, Production, Store/Marketplace connections — same source

API access is gated to ERP Services tier and above (€86/user/month minimum). The Starter tier is not API-eligible. Customers without ERP Services would need to upgrade before any Orcha integration can function.

Conflicting price source flagged: A search snippet from Qualimero's 2026 pricing guide cites €64 / €84 / €159 for similar tiers. The page could not be fetched directly to verify. weclapp.com is the authoritative source — Qualimero may reflect promotional or older pricing.

Sandbox / Testing Environment

"weclapp does not provide a dedicated sandbox. Developers typically use a free trial account or a partner demo instance for testing, which must be managed manually." — maesn.com weclapp API blog

30-day free trial: "Free for the first 30 days | Automatic cancellation" — weclapp.com/en/pricing

"Über das Dashboard kannst du Demodaten in deiner Testinstanz anlegen. Suche das Widget 'Dein Team in weclapp' und klicke auf den grünen Button 'Demodaten anlegen'." — doc.weclapp.com/knowledgebase/wie-kann-ich-in-der-testphase-demodaten-in-meiner-instanz-anlegen

Three substitutes for a real sandbox:

1. 30-day free trial tenant — full feature access, auto-cancels.
2. In-trial demo data button — seeds realistic demo data into the trial.
3. POST /system/createDemoTestSystem endpoint — exists in the OpenAPI spec but lacks any description text. It accepts {label: required, preset: required, all_users?: bool}. Likely provisions a parallel test instance from a named preset — semantics need to be verified hands-on.

Confidence: Medium for sandbox alternatives — /system/createDemoTestSystem is documented as a path but its actual behavior, available presets, and pricing implications are not publicly described.

4. Invoice/Document Submission

weclapp offers two distinct, complementary paths for AP invoice submission via the native API.

Path A: Structured invoice via POST /purchaseInvoice

"create a purchaseInvoice" — POST /purchaseInvoice, accepts a purchaseInvoice schema body — OpenAPI v2 spec, line 13252

Schema fields (from spec line 39073+):

Line item schema (purchaseInvoiceItem, spec line 39278):

Path B: Document upload + automated processing

"This endpoint can be used to quickly turn invoice documents received from suppliers into weclapp purchase invoices. Supported file types are XML, PDF (with or without embedded XML) and images (PNG, JPEG, GIF, TIFF). The documents are uploaded via HTTP multipart request (multiple documents can be uploaded at the same time) and processing is started as a background job. For each document, the appropriate processing strategy is selected based on the file type:

• Image files and PDF files without embedded XML are processed using Optical Character Recognition (OCR). Note: This will only work if your weclapp admin has previously given consent to the use of our OCR provider Klippa App B.V. This can only be done in the weclapp UI.
• XML files and PDF files with embedded XML will be processed using e-invoice detection. If processing is successful, a purchase invoice with status INVOICE_RECEIVED will be created, otherwise a validation error will be shown in the background job log." — OpenAPI v2 spec, line 13708

Endpoint: POST /purchaseInvoice/startInvoiceDocumentProcessing/multipartUpload Request: multipart/form-data with one or more filename parts Response: {result: <jobResult>} — async job; status retrieved via /job/status or webhooks

Practical implications:

• Klippa OCR consent is a one-time admin click in the UI — must be done before this endpoint will accept image/PDF-without-XML files. No API to give consent.
• E-invoice detection (XML, ZUGFERD, FATTURAPA) does not require consent.
• The created invoice is in INVOICE_RECEIVED status — a downstream user/process must verify and progress it through the workflow.
• Multiple documents can be uploaded in a single request.

Path A vs Path B trade-offs

• Path A (structured POST): Orcha controls every field. Supplier can be matched/created via /party, accounts/cost centers assigned per-line, exact tax IDs applied. The invoice can be created in any status from NEW upward. Document file (PDF) can be attached afterward via POST /document/upload?entityName=PurchaseInvoice&entityId={id}.

• Path B (multipart upload): weclapp's own OCR/e-invoice pipeline does the parsing. Less control — the resulting invoice's field accuracy depends on the OCR provider. May overwrite or ignore structured data Orcha already extracted. Useful as a fallback or for raw e-invoice files.

For Orcha's likely use case (we already extract structured data), Path A + post-hoc document attachment is the more deterministic option.

Ancillary creation paths

Several other endpoints can create purchase invoices from upstream documents:

• POST /purchaseOrder/id/{id}/createPurchaseInvoice — derives an invoice from an existing PO (accepts invoiceDate, invoiceNumber, invoiceType, isGross, paymentAmount; optional customAttributes)
• POST /incomingGoods/id/{id}/createPurchaseInvoice — derives an invoice from a goods receipt (no body params)

These are useful for closed-loop scenarios where the PO/goods receipt already exists and Orcha should reconcile against them.

Document attachment and retrieval

• POST /document/upload?entityName={...}&entityId={...}&name={...}&documentType={enum} — attach a file (PDF/PNG/JPEG/etc.) to any entity. documentType enum includes PURCHASE_INVOICE, PURCHASE_INVOICE_ZUGFERD, PURCHASE_INVOICE_FATTURAPA.
• GET /purchaseInvoice/id/{id}/downloadLatestPurchaseInvoiceDocument — retrieve the latest PDF/image attached to a purchase invoice
• GET /document/id/{id}/download — download any document by ID
• POST /document/id/{id}/upload — upload a new version of an existing document

Currency

• Multi-currency supported. currencyId and currencyConversionRate fields on the baseRecordWithMoney ancestor schema. /currency/companyCurrency returns the tenant's home currency.

E-invoicing standards

Document type enum confirms native handling of:

• PURCHASE_INVOICE_ZUGFERD — German hybrid PDF/XML
• PURCHASE_INVOICE_FATTURAPA — Italian e-invoicing
• SALES_INVOICE_XR — XRechnung (sales side)
• SALES_INVOICE_UBL — Universal Business Language (sales side)
• ZUGFERD_VALIDATION — validation document type

Confidence: High for all of section 4 — derived directly from OpenAPI spec.

5. Master Data Access

Suppliers (via /party)

Party schema fields relevant to suppliers (spec line 36911+):

• supplier: boolean (required) — flags a party as a supplier
• supplierActive: boolean — supplier active flag
• supplierNumber: string
• supplierCreditorAccountId → reference to /ledgerAccount
• supplierCreditorAccountingCodeId → reference to /personalAccountingCode
• supplierTermOfPaymentId → reference to /termOfPayment
• supplierPaymentMethodId → reference to /paymentMethod
• supplierShipmentMethodId, supplierDefaultShippingCarrierId
• supplierMinimumPurchaseOrderAmount
• supplierNonStandardTaxId → reference to /tax
• supplierMergeItemsForOcrInvoiceUpload: boolean — controls how OCR-uploaded invoices group line items per supplier
• supplierOrderBlock: boolean
• supplierInternalNote: string — OpenAPI v2 spec line 36553+

Operations (/party):

• GET /party — list with rich filtering (e.g., ?supplier-eq=true)
• GET /party/count
• GET /party/id/{id}
• POST /party — create
• PUT /party/id/{id} — update (supports ?ignoreMissingProperties=true for partial updates)
• DELETE /party/id/{id}

A party can be both customer and supplier simultaneously — both flags can be true.

Confidence: High

Chart of Accounts (/ledgerAccount)

Full CRUD: GET, POST, PUT, DELETE.

Schema (spec line 35615):

• accountNumber: string (required) — e.g., "70000"
• automatic: boolean (required) — system-managed
• balanceSheetItem → enum reference
• parentAccountId → self-reference for hierarchy
• type: enum (required) — CARRY_FORWARD_ACCOUNT, IMPERSONAL_ACCOUNT, PERSONAL_ACCOUNT
• description: string

Confidence: High (spec-confirmed)

Cost Centers (/costCenter, /costCenterGroup)

Full CRUD on both.

costCenter schema (spec line 32409):

• costCenterNumber: string (required, ≤30)
• costCenterType → productionCostCenterType enum (required)
• costCenterGroupId → reference
• description: string

costCenterWithDistributionPercentage is used on invoice line items to split costs across multiple cost centers with percentages.

Cost Types (/costType)

Full CRUD. Schema is simple: just name: string (required, ≤256).

Taxes (/tax)

Schema fields (spec line 43425):

• name: string (required)
• taxValue: decimal (required) — e.g., "19.00"
• taxType: enum (required)
• taxKey (read-only) — system-determined
• accountId, contraAccountId, defaultDiscountAccountId, defaultNominalAccountId, depositAccountId → ledger account references

Lookup helpers:

• GET /tax/findPurchaseTax?recipientCountryCode=DE&dispatchCountryCode=...&taxRateType=...&partyType=...&date=... — returns the appropriate tax for an AP invoice context. Highly useful for tax determination during invoice posting.
• GET /tax/findSalesTax?dispatchCountryCode=DE&... — sales-side equivalent

CRUD also supported plus admin actions POST /tax/configurePurchaseTaxes (per country), /tax/configureSalesTaxes, /tax/resetSystemTaxes.

Confidence: High

Other master data

Filtering and querying

Filter operators (spec line 432): eq, ne, lt, gt, le, ge, null, notnull, like, notlike, ilike, notilike, in, notin

"or" condition: prefix property name with or-. Group with or<groupname>-.

"Filter Expressions (beta): […] Multiple 'filter' parameters may be used if needed. Property references in filter expressions have exactly the same form and semantics as for the individual filter parameters." — OpenAPI v2 spec lines 357-500+

Filter examples from spec:

• GET /party?customerSalesChannel-eq=NET1
• GET /party?createdDate-gt=1398436281262
• GET /party?customerNumber-in=["1006","1007"]
• GET /party?customAttribute4587.entityReferences.entityId-eq=1234
• GET /party?or-name-eq=charlie&or-name-eq=chaplin
• Complex expression: --data-urlencode 'filter=(lower(contacts.firstName + " " + contacts.lastName) = "Ertan Özdil") and (lastModifiedDate >= "2022-01-01T00:00:00Z")'

Pagination: ?page=N&pageSize=M (or ?offset=...). Sort: ?sort=.... Sparse fieldsets: ?properties=.... Eager-load references: ?includeReferencedEntities=....

6. Historical Bookings / Journal Entries

Read access — /accountingTransaction

Endpoints:

• GET /accountingTransaction (list, with full filtering)
• GET /accountingTransaction/count
• GET /accountingTransaction/id/{id}
• POST /accountingTransaction/batchBooking (write — see below)

No PUT, DELETE, or direct POST on the resource itself. This means existing transactions cannot be modified or deleted via the API.

Schema (spec line 28674):

This means Orcha can fetch full historical journal data, including counter-account, debit/credit indicator, tax breakdown, and cost center per line. Use bookingType-in=["INCOMING_INVOICE", "INCOMING_CREDIT_NOTE", "INCOMING_PAYMENT"] to scope to AP-relevant entries.

Write access — /accountingTransaction/batchBooking

"Creates an accounting transaction of type 'impersonal'" — OpenAPI v2 spec line 1892

Body schema:

{
  "batchBooking": {
    "batchBookingRecords": [
      {
        "amount": "...",
        "debitAccountId": "...",      // ledgerAccount
        "creditAccountId": "...",     // ledgerAccount
        "description": "...",
        "taxId": "..."                // tax
      },
      ...
    ],
    "bookingText": "...",
    "costCenterId": "...",
    "currencyId": "...",
    "externalRecordNumber": "...",
    "transactionDate": <timestamp>
  }
}

Constraints:

• Only creates IMPERSONAL type transactions (general ledger postings, not invoice-linked).
• Each record is a single debit/credit pair, not a multi-line journal.
• For invoice-linked transactions (INCOMING_INVOICE etc.), use the /purchaseInvoice endpoint instead — weclapp generates the underlying journal entry automatically when the purchase invoice progresses through its workflow.

Open items — /purchaseOpenItem

Operations:

• GET /purchaseOpenItem (list)
• GET /purchaseOpenItem/count
• GET /purchaseOpenItem/id/{id}
• POST /purchaseOpenItem/id/{id}/createPaymentApplication (apply a bank/cash transaction to clear the open item)
• POST /purchaseOpenItem/id/{id}/updatePaymentState

Schema (spec line 36078, via openItem ancestor):

• amount, amountOpen, amountPaid, amountDiscount (decimals, all required)
• cleared: bool, clearanceDate
• openItemNumber (required)
• openItemType enum: CREDITOR, DEBTOR, CREDIT_NOTE_CREDITOR, CREDIT_NOTE_DEBITOR, etc.
• paymentApplications (array, links to bank/cash transactions)
• purchaseInvoiceId (read-only) — links back to the source invoice

This is the canonical view of unpaid AP — what's still owed to suppliers, what's been partially paid, what discounts apply.

Bank transactions — /bankTransaction

GET and DELETE only. No POST. Bank transactions are imported via separate channels (e.g., HBCI, file import) rather than via API write. This means Orcha cannot push bank statements via API; it can only read existing ones to match against open items via createPaymentApplication.

Confidence: High (all spec-confirmed)

7. Status & Feedback

Webhooks (native, primary path)

"If a webhook is unreachable, the attempt is retried after 1, 5, 30 minutes, 5 hours and 1 day. After one day if the webhook remains unreachable, the webhook is deactivated. […] In the list of webhooks this is logged with an error message." — doc.weclapp.com webhook KB

Payload format:

{ "entityId": "{ID}", "entityName": "{Name}", "type": "{VALUE}" }

with type values: CREATE, UPDATE, DELETE — same source

Webhook setup:

• Via UI: Global Settings → Integration → Webhooks → Create Webhook → choose entity, events (created/modified/deleted), callback URL.
• Via API: POST /webhook with body {entityName, atCreate, atUpdate, atDelete, url, requestMethod, deactivatedDate?, errorMessage?}. Spec-confirmed schema (line 46463).

Webhook entity coverage: The webhook resource accepts an arbitrary entityName (string) — not restricted to a fixed set. Per Maesn's documentation, common entities supported include CUSTOMER, SUPPLIER, INVOICE, CREDIT_NOTE, SALES_ORDER. Whether the full list of ~150 resources is webhook-eligible is not explicitly documented. Hands-on testing would be needed to confirm, e.g., webhook on purchaseInvoice updates.

Critical webhook design considerations:

1. Payload is minimal — only {entityId, entityName, type}. Consumer must call GET /<entity>/id/{id} to retrieve the actual entity content. This adds a round trip per event.
2. Retry ladder is short and aggressive — 1m, 5m, 30m, 5h, 1d, then deactivation. After deactivation, manual reactivation is required (no automatic re-enable). Orcha must monitor webhook health to detect deactivations.
3. Authentication of incoming webhooks: Neither the OpenAPI spec nor the public KB documents any HMAC/signature mechanism. The webhook schema has no secret field. Requests appear to be plain HTTP POSTs. This is a significant gap for production use — Orcha would need to either: (a) verify by source IP allowlist (if weclapp publishes IP ranges); (b) include a secret token in the URL path/query; (c) call back into weclapp to re-fetch and verify; (d) ask weclapp support for the authoritative answer.
4. No replay or event-history endpoint found — missed events cannot be backfilled from a webhook log; reconciliation requires polling lastModifiedDate filters.

Synchronous response on resource operations

Standard REST behavior:

• POST /purchaseInvoice returns 201 with the created entity (including assigned id and version)
• PUT /purchaseInvoice/id/{id} returns 200 with the updated entity (supports optimistic locking via version field)
• DELETE returns 204 No Content on success
• Error responses follow RFC 7807 (problem+json, currently served as application/json) with validationErrors array

Spec quote on validation responses: "Two custom fields have been added to the response structure: 'location' and 'validationErrors'."

Async job tracking

For long-running operations (e.g., the multipart invoice upload, mass operations):

• GET /job/status?jobId=... — poll for completion
• POST /job/abort — cancel a running job

The OCR/e-invoice document upload returns a jobResult body — clients can either poll /job/status or wait for a webhook on the resulting purchaseInvoice creation.

Status states for AP invoices

Useful for tracking the lifecycle of a submitted invoice:

Confidence: High for documented status names; Medium for the exact transition rules (not fully spec-documented).

Unresolved Questions

Suggested Hands-On Testing Plan

A 30-day trial tenant + a freshly created API user provides the test environment. Key scenarios to verify, in order of priority:

Scenario 1: Structured purchase invoice creation (Path A)

1. POST /party to create a test supplier with supplier=true, customer=false, full address, supplierCreditorAccountId (link to an existing ledger account)
2. GET /ledgerAccount?type-eq=IMPERSONAL_ACCOUNT&pageSize=10 to find expense accounts
3. GET /tax/findPurchaseTax?recipientCountryCode=DE&dispatchCountryCode=DE&date=<now> to determine the right tax
4. POST /purchaseInvoice with: supplier from step 1, invoiceDate, internalInvoiceNumber, status=NEW, purchaseInvoiceType=STANDARD_INVOICE, paymentStatus=OPEN, grossPrices=false, items: [{accountId: from step 2, taxId: from step 3, unitPrice: "100.00", quantity: "1", title: "Test"}]
5. Verify response contains an id and version
6. POST /document/upload?entityName=PurchaseInvoice&entityId={id}&name=test.pdf&documentType=PURCHASE_INVOICE with a sample PDF body
7. GET /purchaseInvoice/id/{id}/downloadLatestPurchaseInvoiceDocument to verify retrieval
8. GET /accountingTransaction?bookingType-eq=INCOMING_INVOICE&pageSize=5 to see if the journal entry was generated

Scenario 2: Document upload + OCR (Path B)

1. In the trial tenant UI, grant Klippa OCR consent (admin only)
2. POST /purchaseInvoice/startInvoiceDocumentProcessing/multipartUpload with a sample PDF invoice
3. Capture the jobResult ID, poll GET /job/status?jobId=... until completion
4. GET /purchaseInvoice?status-eq=INVOICE_RECEIVED&createdViaOcr-eq=true&pageSize=5 to find the result
5. Compare extracted fields (supplier, amount, dates) against the source PDF to gauge accuracy

Scenario 3: Webhook reliability and payload

1. POST /webhook with {entityName: "purchaseInvoice", atCreate: true, atUpdate: true, atDelete: false, url: "<your test endpoint>", requestMethod: "POST"}
2. Trigger Scenario 1 again; verify webhook fires within seconds
3. Inspect the payload — confirm it matches {entityId, entityName, type}
4. Critical: Inspect ALL HTTP headers on the inbound request — look for any signature/HMAC header (e.g., X-Weclapp-Signature, Authorization, etc.) not documented elsewhere
5. Repeat with entityName: "accountingTransaction" and entityName: "purchaseOpenItem" to confirm webhook eligibility for these resources
6. Test retry behavior: respond with HTTP 500; confirm retries arrive at 1m, 5m, 30m intervals

Scenario 4: Filter expressiveness and pagination

1. Create 50 test purchase invoices with varying dates and suppliers
2. Test filter=(invoiceDate >= "2026-01-01") and (supplier.supplierNumber-in["S001","S002"]) to confirm beta filter expressions work
3. Test ?or-status-eq=NEW&or-status-eq=INVOICE_RECEIVED&pageSize=20&page=1 for OR filtering with pagination
4. Confirm sorting: ?sort=-invoiceDate&pageSize=10

Scenario 5: Concurrent-request throttling

1. Send 100 parallel GET /purchaseInvoice/count requests
2. Observe whether/when HTTP 429 occurs and queue-wait latencies
3. Calibrate Orcha's connection pool size and retry strategy accordingly

Dead Ends

• Direct fetch of the rendered API portal HTML (https://www.weclapp.com/api2/) — JavaScript-rendered RapiDoc; returns an empty shell. Workaround: fetch the underlying spec at https://www.weclapp.com/api/openapi_v2.yaml directly.
• Looking for an oauth2 security scheme — none. weclapp is API-token-only. No third-party app delegated auth pattern.
• Looking for separate sales/expense voucher restrictions — unlike some other ERPs, weclapp's /purchaseInvoice is fully writable from the start. There is no equivalent of "voucher creation restricted to sales types".
• Searching for a Zapier weclapp app — confirmed absent: "Weclapp has not yet built an integration on Zapier" (zapier.com).
• Searching for Chift/Celigo connectors — no native weclapp connector in either platform's marketplace.
• Direct WebFetch of qualimero.com blog posts — returned 404 from this environment (likely bot-detection); content was only accessible via WebSearch summary snippets.
• Looking for webhook HMAC documentation — neither the OpenAPI spec nor the public KB describes any signature mechanism. This remains an unresolved question.

Sources

Primary (weclapp official)

• weclapp OpenAPI v2 spec (YAML, ~1.4MB, ~46,500 lines) — authoritative source for endpoints, schemas, examples
• weclapp API portal (JS-rendered) and v2 portal
• weclapp pricing page — tier features and prices
• weclapp main site, About
• weclapp partner program
• doc.weclapp.com — API token KB (DE)
• doc.weclapp.com — API overview KB (DE)
• doc.weclapp.com — webhook setup KB (DE)
• doc.weclapp.com — demo data in trial KB (DE)
• doc.weclapp.com knowledgebase root

Intermediaries

• Maesn weclapp marketing page
• Maesn weclapp developer docs (Mintlify) — authoritative for Maesn capability scope
• Maesn integrations directory
• Maesn weclapp API blog post
• Make.com weclapp hub
• Make.com weclapp app — Maxmel Tech variant (richer)
• Make.com weclapp app — #makeitfuture variant (thinner)
• Workato weclapp connector
• Zapier weclapp page (no integration)
• Chift connectors list
• Celigo integration marketplace
• n8n community thread on weclapp
• Tray.io connector hub

Third-party SDKs and tools

• @weclapp/sdk on npm (TypeScript SDK)
• geccomedia/weclapp on GitHub (PHP/Eloquent SDK)
• useblocks/weclapp4py on GitHub (Python SDK)
• kruegge82/weclapp-php-sdk on GitHub (auto-generated from OpenAPI)
• API Tracker weclapp profile

Background / context

• weclapp on Crunchbase
• Qualimero weclapp review (2026) — accessible only via WebSearch snippets in this environment

Retractions

• Initial assumption that purchase invoice creation might be restricted to certain voucher types (drawing on patterns from another ERP's research): retracted. The weclapp OpenAPI spec confirms POST /purchaseInvoice is fully supported with no type restriction beyond the purchaseInvoiceType enum (which includes STANDARD_INVOICE, CREDIT_NOTE, ADVANCE_PAYMENT_INVOICE, etc., all writable).
• Initial reading of Maesn's "Not supported by weclapp" labels for purchase orders, journal entries, and ledger accounts as authoritative statements about weclapp's capabilities: retracted. Cross-checking against the OpenAPI spec confirms these resources exist natively (/purchaseOrder, /accountingTransaction, /ledgerAccount). The accurate reading is "not supported by Maesn's connector for weclapp."
• Retracted Qualimero pricing snippet (€64/€84/€159) — could not verify directly (page returned 404 from this environment); deferred to weclapp.com's own pricing page (€39/€86/€163 monthly), which is the primary source.
• Retracted any specific claim about webhook HMAC mechanism — searched the OpenAPI spec, the public KB, and the wider web; found no documented HMAC/signature mechanism. Listed as an unresolved question rather than asserted either way.
• Retracted any specific list of preset values for /system/createDemoTestSystem — the OpenAPI spec lists no description and no enum constraints. Listed as unresolved.
• Retracted any "no separate webhook fees" claim — appeared in a third-party search snippet only; no primary-source verification found.