Early access — seeking design partners
Connect your product to your customers’ legacy ERPs.
BridgeFlow is being built for B2B software teams that repeatedly integrate with ERP systems. Reuse adapters and operate customer integrations from one place, with mappings and writeback designed for the workflow.
- Design partner
- early access program, not a public launch
- Scoped pilot
- implementation + operation, priced after discovery
- Reusable by design
- adapters reused per ERP, contracts & process reused across ERPs
Your product
Customer ERP deployments
BridgeFlow
Ingest · Normalize
Route · Reconcile
Your product
BridgeFlow
Ingest · Normalize · Route · Reconcile
Customer ERP deployments
Settlement results are written back once the ERP confirms them
A design-partner program, not a shelf product
We are looking for a small number of pilots to build alongside, not selling a finished product.
Built to be reused, not thrown away
An adapter built for an ERP is meant to serve your next customer on that same ERP. What carries over to a genuinely different ERP is the contracts, fixtures, and onboarding process, not the adapter itself.
Writeback means a confirmed ERP posting
Not an HTTP 200 — a result the ERP itself accepted, through an operation it actually supports.
See BridgeFlow in action
One invoice. The whole journey.
From ERP connection settings to verified writeback. Follow one invoice through the prototype, using illustrative sandbox data.
Jump into the flow
Prototype · illustrative dataExplore BridgeFlow
From integration to impact
- How a pilot runsDiscovery, mapping, testing, and monitoring — the stages every pilot moves through.
- Prototype tourA guided look at the current prototype, with illustrative data.
- Candidate workflowInvoice data and settlement writeback is our leading candidate, scoped with a design partner — the first buyer and workflow are not chosen yet.
How a pilot runs
From discovery to a working writeback
Every ERP is unfamiliar until someone maps it. A pilot moves through the same stages regardless of which system it is — discovery and access first, then mapping and test, then monitored operation. The adapter built for one ERP is reused for your next customer on that same ERP; what carries over to a genuinely different ERP is the shared contracts, fixtures, and process, not the adapter itself.
- 1
Discover and get access
Confirm the ERP and version, what operations it actually exposes, and get the permissions needed before assuming an integration is possible.
- Confirm ERP + version
- Find available operations
- Request credentials & access
- Scope the workflow with you
On-prem connectivity is assessed case by case; a managed agent is on the roadmap, not shipped.
- 2
Map and test
One place where records get mapped to your product’s schema, validated against real sample data, and made safe to retry.
- Map ERP fields to your schema
- Validate against sample records
- Batch and schedule where useful
- Handle retries
- Ensure idempotency
- Replay on demand
- 3
Operate and write back
Once mapping is tested, deliver to your product and close the loop — but only report a writeback once the ERP has actually confirmed it.
Your product
The system your customers already work with you through.
Write back to the customer ERP
Posted through a supported ERP operation, once one exists for that ERP — not inferred from a successful API call.
One illustrative record, end to end
example
Ingested from ERP
t+0.0s
Mapped and validated
t+0.2s
Delivered to your product
t+0.9s
Settlement confirmed
t+later
Posted back to ERP
pending
Prototype walkthrough
Prototype · illustrative dataInside the current prototype
Illustrative data from the current prototype, not a live customer deployment — we are still looking for the first design partners to pilot it with. It emphasizes the four things a pilot would actually run on: deployments, connections, request tracing, and the operational queue.
Requests /req_8f3e2d1c
req_8f3e2d1c
Settlement confirmed · writeback pendingIllustrative example · Invoice sync · Customer A
1 Ingested from ERP
t+0.0s
2 Mapped and validated
t+0.2s
3 Delivered to your product
t+0.9s
4 Settlement confirmed
t+later
5 Written back to ERP
pending
Request Flow
Webhook Ingress
Source record captured from the customer ERP
202 Accepted
120ms
Transform
Apply this deployment’s mapping
Mapped
340ms
Delivered to your product
POST to your product’s API
202 Accepted
1.8s
Settlement confirmed
Evidence from your product, not the API response alone
Confirmed
later
Write back to customer ERP
Requires a supported posting operation for this ERP
Pending — no posting operation yet
—
1{2 "event": "invoice.synced",3 "deploymentId": "dep_customer_a",4 "sourceRecordId": "INV-100432",5 "amount": "18450.00",6 "currency": "USD",7 "erp": "customer_erp",8 "metadata": {9 "workflow": "invoice-sync"10 }11}Candidate workflow (not yet chosen)
Invoice data in, settlement writeback out
This is the workflow shape we think is most likely worth piloting first — pulling invoice data from a customer’s ERP into your product, and writing a settlement result back once your product has confirmed it. Which ERP, which buyer, and whether this is really the right first workflow are still unresolved; a pilot is how we’d find out.
Customer ERP → Your product
Invoice records are pulled from the customer’s ERP and mapped to your product’s schema for this specific deployment.
Your product → Customer ERP
Once your product confirms settlement, the result is written back through a supported ERP posting operation — not assumed from an API response.
Discovery → Pilot
Access, permissions, and mapping get worked out with you before anything goes live. The scope narrows during discovery, not after.
Repeat ERP onboarding is the pain we’re chasing. Whatever the first workflow turns out to be, it needs to be narrow enough to prove — invoice data in, settlement writeback out is our leading candidate.
Where this stands today
- Design partner
stage
Recruiting a small number of design partners, not selling broadly yet.
- Illustrative
prototype data
Everything in the product tour is example data, not a live customer deployment.
- Scoped per pilot
pricing & timeline
Implementation and monthly cost are set together after discovery.
For B2B software vendors who repeatedly onboard customers with different ERP systems — not for a single company doing one one-off integration.
Discuss an integrationPricing
A scoped, paid pilot — not a shelf price
Implementation plus monthly operation, priced together with you.
Every pilot starts with a short scoping conversation before we quote implementation and monthly operation for your specific ERP and workflow.
Design partner pilot
One workflow, one ERP, one customer deployment — scoped with you before anything is built.
- Discovery of the ERP’s actual available operations and required access
- Implementation fee for the adapter, mapping, and onboarding package
- A monthly operating fee once the pilot is live
- Direct access to the engineers doing the integration
Priced after scoping, not before
We quote implementation and monthly operation once we understand your ERP and workflow.
Implementation fee + monthly operating fee
The two components of every pilot; the amounts depend on scope.
Scoped to your ERP and workflow
The quote reflects what discovery actually finds, not a generic per-seat or per-transaction rate.
Exact scope and price are set together, after we’ve looked at your workflow and ERP access — not before.
Apply for a pilotApply for a pilot
Building for B2B software vendors integrating ERPs
Tell us about your product, the ERP your customers use, and the workflow you want to pilot.
- Design-partner pilots, scoped one ERP and workflow at a time
- Implementation fee plus monthly operation, priced after discovery
- Direct access to the engineers doing the integration
Frequently asked questions
Common questions, straight answers.
We already have a customer on this ERP. Is a new customer on it a new pilot?
Reusing an existing adapter and mapping may reduce some of the repeated work — we don’t yet have proof it’s actually faster. Either way it isn’t free: a known ERP still needs customer-specific access, credentials, and any custom fields or operations that customer uses. A genuinely new ERP, or a new operation on a known one, is closer to starting over.
Do we still need to grant access and permissions if you’ve integrated this ERP before?
Yes. Access, credentials, and customer-specific mappings are per deployment, not per ERP. Having built an adapter for SAP before does not give us access to your customer’s SAP instance.
Can BridgeFlow connect to an on-prem ERP?
On-prem connectivity is assessed during the pilot, deployment by deployment — it is not guaranteed to work out of the box. A managed on-prem agent is on our roadmap; it is not something we ship today.
When you say "writeback," does that mean the ERP actually posted it?
It should, and that’s the bar we hold ourselves to: a writeback is a confirmed ERP posting, not a successful API call. If an ERP has no supported posting operation for a given result, we say so rather than reporting it as written back.
How long does a pilot take?
We don’t have a fixed number, because it depends on what discovery finds — the ERP, the access you can grant, and how much custom mapping the workflow needs. Timelines are scoped after discovery, not promised upfront.