weclapp ERP — API Integration Analysis for Orcha

Date: 2026-04-10 Vendor: weclapp (acquired by Exact in 2022) Website: https://www.weclapp.com/en/ API Docs: https://www.weclapp.com/api/

1. Summary — Capability Matrix

Overall: HIGH feasibility. weclapp covers nearly all Orcha AP automation needs via direct REST API. The only significant gap is programmatic approval workflow management.

2. API Landscape

Base URL

https://{tenant}.weclapp.com/webapp/api/v2/{entity}

Authentication

• API Token Header (recommended): AuthenticationToken: {api_token}
• HTTP Basic Auth (alternative): username = *, password = API token
• Tokens generated per user under My Settings > API
• No OAuth 2.0, no JWT

Versioning

• v2 (current, recommended) — OpenAPI 3.1.0, stricter validation, JSON-only
• v1 (legacy) — supported for ≥1 year after next major version
• v2 consolidates /customer + /supplier + /contact + /lead → /party

OpenAPI Specs

• JSON: https://www.weclapp.com/api/openapi_v2.json
• YAML: https://www.weclapp.com/api/openapi_v2.yaml
• 670 endpoint paths total across all resources
• Changelog: https://www.weclapp.com/api/changelogV2.html

Rate Limits

• No fixed published limits — adaptive load management
• Concurrent request limit per tenant with queue (waits up to 30s)
• Returns HTTP 429 when queue exhausted
• Recommendation: exponential backoff, 60+ second timeouts, prefer webhooks over polling

SDKs & Client Libraries

3. Write Capability Verification

Confidence: HIGH. Write endpoints are extensively documented in the OpenAPI spec and confirmed by iPaaS connectors.

Evidence:

• OpenAPI 3.1.0 spec lists POST/PUT/DELETE methods on all core entities
• Make.com (makeitfuture app, 37+ modules) confirms write operations for invoices, parties, orders, quotations
• Workato connector supports generic Create/Update Record against any entity
• Official TypeScript SDK generates full CRUD services per entity
• Community Python/PHP libraries implement POST/PUT operations

Key Write Endpoints for Orcha

4. iPaaS & Middleware Findings

Key insight: The Make.com makeitfuture app is the most comprehensive iPaaS connector, but for Orcha's use case, direct API integration is the clear winner given weclapp's excellent API documentation and OpenAPI spec.

5. Alternative Integration Channels

Webhooks (Native)

• Full CRUD on /webhook endpoint
• Events: CREATE, UPDATE, DELETE per entity (e.g. purchaseInvoice.created)
• Lightweight payload (entityId, entityName, type) — requires follow-up GET
• Retry policy: 1min → 5min → 30min → 5hrs → 1 day; deactivated after 1 day of failures
• Config: Settings > Integration > Webhooks

DATEV Export (Native)

Strong native DATEV support — important for German market:

1. Buchungsdatenservice — booking records + document images → DATEV
2. Rechnungsdatenservice 1.0 — invoices, credit notes, cash transactions → tax advisor
3. Journal-based export — all journal data
4. CSV fallback — for non-DATEV systems

CSV Import/Export (Native)

• Import/Export Wizard (Global Settings > Import/Export)
• Template-based master data import
• List-based exports

Maesn Unified API

weclapp is supported by Maesn (European unified ERP/accounting API):

• Read/write: accounts, bank accounts, bills, invoices, credit notes, customers, suppliers, payments, journals
• Webhook support
• Covers 12+ other ERP systems — potential future leverage

E-Invoice Formats

• ZUGFeRD and XRechnung supported natively

6. Licensing & Access Requirements

Pricing Plans

What the Customer Must Buy/Enable

Customer Setup Checklist

1. ☐ Active weclapp account on ERP Trade plan (or ERP Services if only financial accounting needed)
2. ☐ Admin user generates API token (My Settings > API)
3. ☐ Provide Orcha with: tenant subdomain + API token
4. ☐ Configure webhook subscriptions for relevant entities (optional, for real-time sync)
5. ☐ Ensure chart of accounts and cost centers are set up in weclapp
6. ☐ Map weclapp tax codes to Orcha's tax categories

Ongoing Costs for Customer

• weclapp subscription (per user/month, plan-dependent)
• No additional API usage costs identified
• API token rotation at customer's discretion (regenerating invalidates previous tokens)

7. Orcha-Specific Deep Dive

7a. Reference Data Sync (Inbound to Orcha)

7b. Document Push (Orcha → weclapp)

v2 note: In v2, secondary properties like supplierNumber and costCenterNumber are removed — use *Id references instead. Unknown properties return HTTP 400.

7c. Approval Management

This is the primary gap. weclapp has an internal authorization/workflow engine for purchasing, but it is not exposed via the API. Workarounds:

• Use custom attributes on purchaseInvoice to track Orcha's approval status
• Use weclapp's /task endpoint to create approval tasks
• Manage the approval workflow entirely within Orcha and only push the final approved invoice to weclapp

7d. Payment & Lifecycle Tracking

8. Recommended Path Forward

Architecture: Direct API Integration (Recommended)

Why Direct API Over Alternatives

• vs. iPaaS (Make/Workato): Direct is simpler for Orcha's server-to-server use case. iPaaS adds cost and latency without meaningful benefit since weclapp's API is well-documented.
• vs. Maesn unified API: Consider Maesn only if Orcha wants to support many ERPs through a single integration layer. For weclapp specifically, direct API gives more control and avoids dependency.
• vs. DATEV bridge: DATEV export is one-directional (weclapp → DATEV). Not suitable for Orcha's write requirements.

Phased Integration Plan

Phase 1 — Reference Data Sync

• Sync suppliers (GET /party), chart of accounts (GET /ledgerAccount), cost centers (GET /costCenter), tax codes (GET /tax), payment terms (GET /termOfPayment)
• Set up webhooks for real-time updates on reference data changes

Phase 2 — Invoice Push

• Create purchase invoices (POST /purchaseInvoice) with line items, cost center assignments, tax codes
• Upload PDF attachments (POST /document/upload)
• Handle credit notes and cancellations

Phase 3 — Payment Lifecycle

• Read open AP items (GET /purchaseOpenItem)
• Apply payments and update payment states
• Subscribe to invoice status webhooks for real-time tracking

Phase 4 — (Future) Approval Bridge

• If weclapp exposes approval APIs in the future, integrate
• Until then: manage approvals in Orcha, push only approved invoices to weclapp

Risk Factors

9. Sources

Official

• weclapp API Documentation (Interactive)
• OpenAPI v2 Spec (JSON)
• OpenAPI v2 Spec (YAML)
• API v2 Changelog
• weclapp Pricing
• weclapp Webhooks Guide
• weclapp DATEV Export
• weclapp Data Import Guide
• weclapp Roadmap — Invoice OCR

SDKs & Libraries

• Official TypeScript SDK
• weclappy (Python)
• pyweclapp (Python)
• geccomedia/weclapp (PHP/Laravel)

iPaaS & Middleware

• Make.com weclapp Integration
• Workato weclapp Integration
• Synesty weclapp Add-on
• Maesn weclapp Integration

Third-Party Guides

• Qualimero — weclapp API Guide
• Qualimero — weclapp Pricing Guide
• Maesn — weclapp API Blog
• OMR Reviews — weclapp Pricing
• Wals.pro — Postman Collection

10. Requirements Verification — Jira + Weclapp via Orcha

Context

A customer uses Jira as their PO/approval hub and weclapp as ERP/source of truth for inventory, GRNs, and accounting. Orcha sits in the middle: matching invoices against Jira POs (approval context) and weclapp POs + GRNs (quantity/receipt checks), then pushing ready invoices to DATEV.

10a. Weclapp as ERP / Source of Truth

10b. Partial Shipments & Advance Payments

10c. Webhooks & Event Notifications

10d. Cross-System Behavior (Jira + Weclapp via Orcha)

10e. Key Endpoint Details for Implementation

Purchase Order Lifecycle

Status enum (supplierOrderStatusType):
  ORDER_ENTRY_IN_PROGRESS → ORDER_ENTRY_COMPLETED → ORDER_DOCUMENTS_PRINTED → CONFIRMED → CLOSED
                                                                                        → CANCELLED

Read-only flags (updated automatically):
  received: boolean   — true when all items fully received via GRNs
  invoiced: boolean   — true when all items fully invoiced
  paid: boolean       — true when all open items paid

Advance payment:
  advancePaymentStatus: OPEN | PAID (read-only)

Purchase Invoice Lifecycle

Status enum (purchaseInvoiceStatusType):
  NEW → OCR_VERIFICATION → INVOICE_RECEIVED → INVOICE_VERIFICATION → INVOICE_CHECKED
      → ENTRY_COMPLETED → DOCUMENT_CREATED → OPEN_ITEM_CREATED → CANCELLED

Payment status (paymentStatus):
  OPEN | PAID | NO_OPEN_ITEM | UNKNOWN | CLEARED_WITH_CREDIT_NOTE | CREDIT_NOTE_CLEARED

Invoice types:
  STANDARD_INVOICE | ADVANCE_PAYMENT_INVOICE | PART_PAYMENT_INVOICE
  PREPAYMENT_INVOICE | FINAL_INVOICE | CREDIT_ADVICE | CREDIT_NOTE

3-Way Matching Data Model

purchaseInvoice
  └── purchaseInvoiceItems[]
        └── purchaseInvoiceItemRelationships[]
              ├── purchaseOrderItemId    → links to PO line item
              ├── incomingGoodsItemId    → links to GRN line item
              └── quantity               → matched quantity

GRN Creation (Two Paths)

Path 1: From PO
  POST /purchaseOrder/id/{id}/createIncomingGoods
  Body: { additionalPurchaseOrderIds: [...], customAttributes: {...} }
  → Returns incomingGoods entity

Path 2: Direct + Link
  POST /incomingGoods                              → create GRN
  POST /incomingGoods/id/{id}/addPurchaseOrders    → link POs afterward
  Body: { ids: ["poId1", "poId2"] }

10f. Gaps & Workarounds Summary

Verdict: weclapp covers 100% of these requirements with minor mapping needed for PO payment lifecycle status. The native 3-way matching data model is particularly strong and aligns exactly with Orcha's cross-system matching workflow.