ERP Integration Connector Platform — NetSuite-first

One connector, many independent customer accounts · recorded walkthrough

A single, reusable integration platform that connects many customers' ERP accounts to one product. Per-customer differences — credentials, base URL, field names, custom fields, auth mode — are data, not code branches. NetSuite first, via SuiteTalk REST + SuiteQL, SuiteTalk SOAP, RESTlets and SuiteScript; Dynamics 365 and QuickBooks sit behind the same interface. Sync is bidirectional and resumable, idempotent, conflict-aware and observable.

What the recording shows — five scenarios, one connector

1 · Provision

The platform provisions fresh customer accounts and backfills them — paged, truncated and exhausted — through the real API surface.

2 · Isolation

Two tenants never share records. ERP internalIds are per-account, so ids collide across customers while the platform's links do not.

3 · Customisation

A customer whose schema is untrustworthy — custom fields and drifted types — is handled as configuration, with no code branch per customer.

4 · Conflict

Both sides changed the same record. The platform detects it at field level and resolves it, instead of a last-write-wins coin toss on ledger data.

5 · Backlog

A deep backlog is queued, a worker lease is stranded on purpose, and the drained queue is caught up by parallel workers.

Throughout

Counts are read from the platform's own metrics, not written by the demo. Nothing is asserted that the run does not print.

Under the surface

One-to-many: a single ErpConnector interface serves every customer; adding an ERP is one connector + one register() call.
Reliability: server-sourced watermarks per (connection, entity, direction); per-tenant sealed credentials; idempotency records so a retried write cannot duplicate; field-level conflict records; per-connection circuit breakers and throttling that honour Retry-After.
Faults on purpose: a NetSuite-equivalence harness — a service shaped like the NetSuite API — injects faults (Chaos Monkey-style: throttling, a write that commits then loses its response, an outage, a mid-run schema change).
Measured: load-tested with Locust (multi-tenant sync contention, signed SuiteScript ingest at volume); integration tests under pytest.

Software stack & Python libraries

HTTP API: fastapi served by uvicorn; pydantic v2 for request models and pydantic-settings for configuration.
Data: sqlalchemy 2 ORM over PostgreSQL with psycopg2 — every query scoped by tenant_id, with row-level security underneath.
Outbound HTTP: httpx for the async calls into each ERP account.
Credentials: cryptography — per-tenant secrets sealed with keys HKDF-derived from a master key (never stored in the clear, never rotated with the data).
CLI & ops: typer + rich for the terminal tooling; a resident worker draining an outbox with leases; prometheus-client for metrics.
Quality: pytest for the ~190-test suite and ruff for lint — both pinned in requirements-dev.txt.
Load testing: locust + gevent in a deliberately separate virtualenv (five scenario files: smoke, soak, multi-tenant sync contention, signed SuiteScript ingest, webhook volume).
In-account: SuiteScript 2.x scripts deployed inside the simulated NetSuite; the admin dashboard is React + Vite.

Pythonasync workersPostgreSQL SuiteTalk REST / SuiteQLSuiteTalk SOAP RESTletsSuiteScriptLocustpytest Prometheus

Recorded from the live console: the simulated NetSuite account as a multi-window desktop — an Omni-style workspace of floating windows (draggable, resizable, minimize tray) — with each window in its own browsing context, and the numbers read from the platform's own endpoints.