Systems & Data

No-API Integrations and Legacy Data Migration

Getting systems that were never meant to talk to each other to do so reliably — including integrations with no public API — and migrating legacy data with a reconciliation report instead of a hopeful import.

Read the approach Discuss this engagement →

When there is no API to integrate with

Not every system a business depends on offers an API. Marketplaces, legacy vendor tools, and inboxes full of order confirmations all carry data a product needs, without a documented integration surface to pull it from. This service is built around solving exactly that: integrating systems with no API by working with the interface they do expose — an inbox, a legacy database, a document format — and migrating legacy data with an auditable reconciliation report rather than a one-time import script.

In depth

Integrating without an API

On DinDin, neither Grubhub nor DoorDash exposed the order API the workflow needed, so the integration authenticates to a shared inbox instead, parses each marketplace's HTML order-confirmation email, matches the merchant, deduplicates by the marketplace's own order number, and writes a native DinDin order that flows to the same kitchen printer as an order placed on the restaurant's own site. The result is one order workflow for restaurant staff regardless of which channel it arrived on, with no manual re-keying, even though the integration itself has no formal API to call.

In depth

Legacy-data migration with reconciliation

Migrating legacy data is not a single import step; it is a reconciliation problem. Omnitech CRM's migration from a long-running legacy Perfex CRM installation uses transactional, idempotent migrators that reconcile legacy identifiers against the new schema and explicitly report the records that require a human decision before import, rather than guessing. Eight legacy roles were preserved through that process specifically so staff access rules carried over instead of being silently reset.

Fit

Who this helps

Businesses that need data from a marketplace, vendor tool, or partner system with no public API.
Teams migrating off a legacy CRM, database, or vendor platform who need staff access and records preserved, not just copied.
Operators already running WordPress/WooCommerce who need it extended rather than replaced.
Anyone who has been offered a 'straightforward import' and wants to know what it will actually miss.

Scope

What's in scope

Integration design for systems with no public API
Email- and document-based data ingestion
Legacy database and CRM migration
Transactional, idempotent migration tooling
Reconciliation reporting for records that need a human decision
WordPress/WooCommerce extensions where a client already runs on that stack

Deliverables

What you get

No-API integration pipeline
Legacy migration and reconciliation tooling
Deduplication and identity-matching logic
Migration reconciliation report

Evidence

Related work

DinDin

Complete restaurant technology suite connecting online ordering, POS, back-office operations, kitchen displays, customer displays, and marketplace orders.

Omnitech CRM

Multi-tenant CRM and revenue platform with fail-closed tenant isolation, scoped permissions, configurable pipelines, lead conversion, and legacy-data migration.

Related technical writing

Integrating a System With No Public API → Legacy-Data Reconciliation Is Not an Import Script →

Next step

Want to talk through your situation?

Let's discuss the constraints, the current system, and what a first engagement would look like.

Start a conversation Explore all services →

Questions and answers

Questions about no-API integrations and legacy migration

How do you integrate with a system that has no public API?

By working with whatever interface the system does expose, even if it is not designed for integration. On DinDin, Grubhub and DoorDash orders arrive as HTML confirmation emails rather than through an order API, so the integration authenticates to a shared inbox, parses those emails, matches the merchant, and writes a native order — the inbox becomes the integration surface.

What does 'reconciliation' mean in a legacy-data migration?

It means matching legacy identifiers against the new schema and explicitly reporting the records that cannot be resolved automatically, so a human makes the final call instead of the migration guessing. Omnitech CRM's migration from Perfex CRM uses transactional, idempotent migrators built specifically for this, preserving eight legacy roles in the process.

How is duplicate or re-keyed data avoided when ingesting from marketplaces or emails?

By deduplicating on an identifier the source system already guarantees is unique — on DinDin, that is each marketplace's own order number — rather than re-deriving identity from free-text content, which is what allows the same confirmation email to be safely reprocessed without creating a duplicate order.

Can legacy staff permissions carry over during a CRM migration?

Yes, when the migration treats roles as data to reconcile rather than something to reset. Omnitech CRM's migration preserved eight legacy roles from the outgoing Perfex CRM installation so existing staff access rules carried over into the new system instead of being rebuilt from scratch.

Explore all services →