Legacy database to REST API integration, done for you.
Your enterprise prospect's data lives in an internal SQL database — the system of record behind an application nobody wants to touch. We design, build, and operate the read-only bridge from that database into your API, so the deal closes without their database administrator losing sleep.
"Just query our database" is easy to say and terrifying to grant.
When the customer's system has no API, someone eventually says the obvious thing: the data is right there in the database — just read it. Technically true. But their database administrator hears something different: an outside vendor holding credentials to the system of record, running queries nobody reviewed, at hours nobody agreed to, with load nobody measured.
That conversation is where these deals stall — not on whether the integration is possible, but on whether it can be trusted. So we built the bridge to answer the trust question first, and we bring those answers to the scoping call with their team.
What a legacy-database integration actually involves
- The database outlived its documentation — terse column names like EMP_ID_NUM and DT_HIRED, conventions that live in one veteran's head, and an application on top that nobody wants to modify.
- Access is the negotiation — their administrator will grant a read-only account, on their schedule, with their rules. The integration has to be designed around that reality, not around wishful write access.
- Production load is a real concern — this database runs their business during the day. An extraction that table-scans millions of rows at 2pm is how you lose the customer's trust permanently.
- Data needs cleaning on the way out — zero-padded IDs, dates in local formats, currency stored as text with commas, "N/A" strings where numbers should be. It parses fine until it doesn't.
- The rows keep changing — this isn't a one-time export. New and updated records need to flow continuously, without re-sending everything and without missing a window when something fails.
Read-only by construction, incremental by default, reconciled every run.
Extract through a read-only tunnel
Every query runs inside a transaction declared read-only at the database level — the bridge cannot write to their system even in a bug scenario. Short-lived connections, batched reads, statement timeouts, replica-friendly.
Pull only what changed
After the first load, each run extracts just the rows changed since the last successful one, tracked by a watermark that only advances after the run reconciles — a failure can never silently skip its window.
Validate, then deliver to your API
Every row checked against a strict schema, normalized, and posted to your endpoint as clean JSON. Every run must balance: rows in = delivered + skipped + quarantined. Failures are held with the exact reason.
Database questions we hear on scoping calls
Does Shapewire need write access to our customer's database?
No — and not just as a policy. Every extraction query runs inside a database transaction that is declared read-only at the protocol level, so the bridge cannot modify their system of record even if a bad query ever slipped through review. A read-only account on their side is all we ever ask for.
Will the extraction put load on their production database?
The bridge is built to be a polite guest: short-lived connections, batched cursor reads instead of giant scans, a statement timeout on every query, and scheduling that respects their quiet hours. If they have a read replica, we happily point at that instead of production.
Do you rescan the entire table every run?
No. After the first full load, each run extracts only what changed since the last successful one, tracked by a watermark — the highest change-timestamp or ID fully processed. The watermark only advances after a run reconciles, so a failed run can never silently skip its window of data.
Which database engines do you support?
PostgreSQL is supported in production today. Other engines — MySQL, Oracle, SQL Server — are scoped as part of the engagement: the read-only, incremental, reconciled pattern is the same, and the engagement model exists precisely so one customer's unusual stack becomes our problem, not yours.
Is a customer's database standing between you and a signed deal?
Grab 30 minutes — tell us what the system is and what's blocking the close. Pricing works like this →
Prefer email? hello@shapewire.io