Integration Leverage Catalog
Purpose: A registry of external resources — OSS connectors, templates, specs, and tooling — we can leverage to grow the number of ERP / system integrations we support faster than building each from scratch. This is a “what can we borrow, and how” reference, not a design doc.
Scope discipline: Our current focus is order automation (see the playbook
half below). Sources are tagged [now] if they help the order-automation core today,
or [later] if they belong to the deferred expansion (AR/AP, accounting, ecommerce).
Don’t pull [later] sources into the stack until the order-automation playbook is
standard across the connectors we already have.
Related internal docs (complement, don’t duplicate):
docs/onboarding/SOP-OB-002-new-erp-integration.md— the new-ERP build processdocs/onboarding/SOP-OB-003-erp-integration-build-checklist.md— the checklistdocs/integration-architecture-pattern.md— the architectural patterndocs/architecture/erp-sync-architecture.md— the read/sync pipeline
How our integrations are shaped (so you know which source feeds what)
Section titled “How our integrations are shaped (so you know which source feeds what)”Every integration has two halves. Match each leverage source to the half it serves:
| Half | What it does | Our runtime | Order-automation surface |
|---|---|---|---|
| Read / Sync | Pull customers, products, ship-to → Iceberg → Typesense | Dagster + DLT (Python) | customers, products, shipping_addresses |
| Write / Action | Push orders into the ERP | IERPService (TypeScript) | createOrder (+ approveQuote, updateOrder, filterInvalidItems) |
| Auth / Onboarding | Store creds, run OAuth, let customers self-connect | Nango (self-hosted, free tier) | all of the above |
A leverage source is useful in one of three ways:
- RUN — drop it directly into our stack (only DLT-native sources qualify).
- LEARN — read it to discover an API’s surface, then write our own (the Business Edge path).
- REFERENCE — first-party spec/SDK to generate or validate a client.
A. Auth / Onboarding layer
Section titled “A. Auth / Onboarding layer”| Source | License | Use | Tag | Notes |
|---|---|---|---|---|
| Nango (self-hosted) | Free tier = Auth + Proxy; Functions runtime = enterprise | RUN | [now] | Credential vault + OAuth lifecycle + embeddable Connect UI + auth proxy. NANGO_ENCRYPTION_KEY (base64 32-byte, no rotation support) in 1Password. Proxy is HTTP-only — Eclipse E4’s MSSQL reads can’t proxy (vault-only there). |
| Nango providers.yaml | MIT (verify) | REFERENCE | [now] | 800+ providers’ OAuth/base-URL/auth configs. Even for custom ERPs, copy the auth-mode shape into our own provider config. |
B. Read / Sync leverage (feeds DLT + Dagster)
Section titled “B. Read / Sync leverage (feeds DLT + Dagster)”| Source | Coverage | License | Use | Tag | Notes |
|---|---|---|---|---|---|
| dlt verified-sources | 30+ prebuilt (SQL, Salesforce, etc.) + generic REST API + SQL DB sources | Apache-2.0 | RUN | [now] | ★ Highest leverage — we already run DLT. The generic rest_api source covers any JSON ERP with config-only setup. Any SQL-backed ERP via the sql_database source. |
| dltHub source definitions / AI workbench | 9,700+ REST API source definitions it can scaffold | Apache-2.0 (tool) | RUN/LEARN | [later] | Scaffolds a typed DLT REST source from an API’s shape. Good accelerant when we add a new JSON ERP. |
| Singer taps (Meltano Hub) | 300+ community taps incl. some ERP/accounting | Mostly MIT/Apache (per-tap — verify) | LEARN | [later] | Variable quality / many abandoned. Read for API surface + pagination; rarely worth running as-is. Python, so portable to DLT logic. |
| Airbyte connectors | 600+ incl. NetSuite, accounting | ELv2 / mixed (not fully OSS) | REFERENCE | [later] | Java/Python CDK = runtime mismatch with DLT. Use as API-surface reference, not to run. License blocks productizing as a hosted connector. |
C. Write / Action + API-surface leverage (feeds IERPService)
Section titled “C. Write / Action + API-surface leverage (feeds IERPService)”| Source | Coverage | License | Use | Tag | Notes |
|---|---|---|---|---|---|
| Pipedream components | 1,000+ apps, 1,000s of actions/sources (incl. niche ERPs like Business Edge) | Source Available (since 2022-01-03) | LEARN | [now] | ★ How we discovered the Business Edge API. Read freely to learn endpoints/auth/payloads; do not vendor current code without a license review. |
| pipedream-mit (pre-2022 fork) | Pipedream snapshot before MIT removal | MIT | LEARN/RUN | [now] | Freely reusable but frozen/stale. Use when you need MIT-clean reference code; re-verify the API still matches. |
| Nango integration-templates | TS syncs+actions for NetSuite, QuickBooks, Xero, Sage Intacct, Odoo, Zoho | MIT (verify) | LEARN | [later] | Commodity-system templates. netsuite-tba (PO/invoice/customer create+update) and quickbooks (~50 actions) are complete. Map to our IERPService when we expand beyond order automation. |
| n8n nodes | 400+ app nodes | Sustainable Use License (fair-code) | REFERENCE | [later] | Node.js, readable. Another API-surface reference when Pipedream lacks an app. License blocks SaaS resale of the code. |
D. ERP-specific OSS connector code
Section titled “D. ERP-specific OSS connector code”From prior deep research (see memory: ERP integration expansion research 2026-06-14). Verify every license before vendoring; learning is always fine.
| Target ERP | OSS repos | License (per research — verify) | Use | Tag |
|---|---|---|---|---|
| NetSuite | fylein/netsuite-sdk-py, jacobsvante/netsuite, restsuite | MIT | LEARN/RUN | [later] |
| Dynamics 365 Business Central | microsoft/ALAppExtensions | MIT | LEARN | [later] |
| Epicor (Kinetic/P21-adjacent) | community: TAIT, Epycor, bconner samples | mixed — verify | LEARN | [now] (P21 context) |
| On-prem relay (AS/400, greenscreen, on-prem SQL) | cloudflared, frp | Apache-2.0 | RUN | [later] (WSO2/legacy ERP path) |
| Embeddable iPaaS building block | Nango (above) | ELv2/free-tier | RUN | [now] |
E. First-party vendor specs (REFERENCE — generate/validate clients)
Section titled “E. First-party vendor specs (REFERENCE — generate/validate clients)”| ERP | Spec artifact | Notes |
|---|---|---|
| Prophet21 | OData $metadata (per-instance) + XML TransactionSet schema | We already consume; v3/v4 detection. |
| NetSuite | SuiteTalk REST OpenAPI + SuiteQL | OpenAPI generates a typed client. |
| Acumatica | Contract-based REST OpenAPI (per-instance) | Endpoint published by the instance. |
| Business Edge (CI Inc) | Derived from Pipedream component (POST .../export.json, Basic DevKey:) | No public docs — Pipedream is the de-facto spec. |
| SAP Business One | Service Layer OData ($metadata) | See docs/sap_integration_design_comprehensive.md. |
Prioritized shortlist — min work / max impact for order automation
Section titled “Prioritized shortlist — min work / max impact for order automation”In order, the leverage that moves the order-automation playbook forward now:
- Nango self-hosted (Auth + Proxy) — single credential vault + self-serve Connect UI for every order-automation connection.
[now] - dlt verified-sources
rest_api+sql_database— config-only read/sync for any new JSON or SQL ERP, directly in our existing Dagster stack.[now] - Pipedream components (LEARN) — fastest way to discover a niche ERP’s API surface before writing the
IERPServicewrite path.[now] - First-party OpenAPI/$metadata (REFERENCE) — generate typed clients where the vendor publishes a spec (NetSuite, Acumatica, SAP B1).
[now/later]
Deferred until the playbook is standard: Nango integration-templates, Airbyte/Singer at scale, the accounting/ecommerce sources, and the broader ERP-specific OSS connectors.
Maintenance
Section titled “Maintenance”- This is a living catalog. When you evaluate a new source, add a row with its license and use mode (RUN/LEARN/REFERENCE) — license is the part that bites later.
- When a
[later]source gets adopted, move its details into the relevant design doc and leave the catalog row pointing there.