Stone Age SoftwareHouston, TX
System Integration · Houston, TX

Right now, your system integration layer is your staff.

Copy from one screen, key it into two more, and hope all three agree by Friday. When they don't, the discrepancy surfaces wherever it does the most damage. Real interfaces close that gap: APIs, pipelines, and queues that move the record once, retry when the far end is down, and raise a flag the moment they stop.

Map your interfaces What we do
Sound familiar?

Six places the handoff happens by hand

Each one is a point where two systems meet and a person fills the gap between them.

The same order is keyed three times

It arrives by email, goes into the ERP, then the WMS, then the customer's portal. Three chances to be wrong, and no one owns the difference.

Two systems, two versions of the truth

Inventory says one number, the ERP says another, and everyone has a favourite. Nobody has ever written down which one is authoritative.

Case study scrap paperwork re-checked against live inventory after it is filed

The interface broke last Tuesday

You found out today, from a customer. Nothing was watching the job, so a silent failure sat there quietly aging for a week.

The vendor says they have an API

Everyone does. The question is whether it exposes the fields you need, at the volume you need, without a per-call fee that ruins the case.

It's a nightly CSV on an FTP server

Written years ago, still running, still the most reliable thing you own. Nobody knows what happens the day the file arrives twice.

Everything integrates through a spreadsheet

Someone exports from one system, tidies it in Excel, and imports it into the next. That is a scheduled job being run by a person.

Capabilities

Four ways data crosses a boundary

Whatever the transport, three things have to hold: it retries, it can't duplicate a record, and a failure raises an alarm rather than waiting to be discovered.

APIs Over Legacy Systems

A modern front door on a core that was never designed to have one.

  • REST endpoints over an ERP, AS/400, or database that only speaks its own language
  • Events and webhooks published outward, so downstream systems stop polling all day
  • Read-only first — expose the data safely before anything is allowed to write back
  • Pagination, rate limits, and versioning so an integration can't take the core down
  • Database-level or screen-level access when there is honestly no other way in

Case study a queue-driven service that works a warehouse system's real screens

Data Pipelines & ETL

Moving data out of the operational systems into somewhere you can query it.

  • Extraction from ERP, WMS, CRM, and the databases nobody wants to query live
  • Incremental loads with watermarks, instead of re-reading ten years every night
  • ELT into a warehouse when the transformation is better done after landing
  • Record counts and control totals that fail loudly when a load comes up short
  • Backfills and replays treated as routine operations rather than an emergency

Case study a mailbox-to-order pipeline that reports every dropped line

Middleware, Queues & Reliability

The unglamorous half of integration: what happens when the other end is down.

  • Message queues and brokers, so a slow consumer never stalls the producer
  • Idempotency keys — a retry updates the order rather than creating a second one
  • Backoff, dead-letter queues, and a replay procedure your team can run at 6am
  • File and batch interfaces done properly: SFTP, flat and fixed-width, checksums
  • Monitoring on every interface, so the first person to notice a failure works here

Case studies a request board that reconciles with the issue tracker every fifteen minutes · an upload queue where every document carries its state and reason

SaaS, Webhooks & Everyday Glue

Connecting the tools you already pay for, so nobody's job is copy-and-paste.

  • Webhook receivers that verify signatures and survive duplicate deliveries
  • Accounting, CRM, e-commerce, payment, and shipping systems wired to each other
  • Credentials and API keys stored properly, not pasted into a flow somebody built
  • An audit record of what crossed the boundary, when, and on whose authority
  • An honest 'buy the off-the-shelf connector' when one already does the job

Case studies a local service that hands badge scans to a web page · an intake board that keeps working when the issue tracker is down

Two answers that keep integration small

The first: five interfaces between systems you'll still own in ten years are best served by five interfaces, with no hub, canonical model, or renewal date to carry. We'll build the small thing, and show you where the threshold for a platform genuinely sits, so you'll recognize it if you ever reach it.

The second: integration works best once the business names the system of record — for inventory, for pricing, for the customer. We put every conflict on one page, show who writes which field, and build the interface once that direction is decided. A case in point: a variance workbook pulled from a mailbox into a persistent register.

Where it pairs well

  • Trading-partner traffic — X12, EDIFACT, routing guides — is its own deeper subject over on EDI & B2B integration
  • WMS, TMS, scanners, and multi-client billing live on the 3PL & warehouse systems page
  • An API layer is often the first phase of a migration — it lets the core be replaced behind a stable boundary
  • When the interface is slow rather than broken, that's workload optimization: batch windows, queries, and job scheduling
  • If the system on the far end is undocumented and has no tests, code rescue comes first

The documents that never integrate

Some partners will only ever send a PDF or an email. That's an extraction problem, not an interface problem — different tool, same goal.

Once the data lands somewhere

A pipeline is only worth building if someone reads the result. Power BI and reporting are the reason most of these get funded.

Interfaces need screens too

Exception queues, mapping tables, and a replay button are custom software. Without them, every failure becomes a call to us.

See the shape of the work

Integrations are hard to describe and easy to recognize — the project write-ups show what we actually built and what it replaced.

Toolkit

What we work in

REST & JSON OpenAPI / Swagger Webhooks SOAP & XML Python & FastAPI Flask Go C# / .NET Java Node.js & TypeScript Erlang & Elixir PostgreSQL SQL Server ODBC & linked servers RabbitMQ Azure Service Bus Redis Celery & job queues Dead-letter queues & replay Idempotency keys OAuth 2.0 & API keys SFTP, FTPS & AS2 Flat & fixed-width files XML & EDI payloads Azure Data Factory Airflow & scheduled jobs Scala & Spark pipelines Power Automate Data warehouses (Postgres, SQL Server, Fabric) Logging & alerting
Questions we get

Straight answers

Do we need an integration platform or an enterprise service bus?

Almost certainly not, and this is worth hearing before a licence gets signed rather than after. A hub starts earning its keep when endpoints arrive faster than anyone can name them — dozens of systems, new partners every month, somebody employed to keep the mappings current. Short of that, you have taken on a second platform to run on top of the interfaces you still have to write. Our preference is to write the interfaces and leave you nothing extra to renew.

Our main system has no API. Is that a dead end?

No, and it is the ordinary case rather than the unlucky one. We work at whatever level the system honestly offers: a supported API if one exists, the database directly if it does not, a file interface it already produces, or in the worst case the same screens your staff use. The point is to put one documented boundary in front of it so everything downstream integrates with that boundary — which means the core can be replaced later without breaking every consumer.

Should this be real-time?

Sometimes, and less often than people assume. A nightly file drop that runs every night beats a real-time interface that fails on Fridays, and plenty of processes genuinely do not care whether the data moved four seconds ago or four hours ago. Ask what decision the freshness changes. If nobody acts on it until morning, batch is not a compromise — it is the correct design, cheaper to run and far easier to re-run when something goes wrong.

Our two systems disagree. Can integration fix that?

Yes, once one question is settled: which system is authoritative for each piece of data — inventory, customer records, pricing, credit terms. That is a business decision rather than a technical one, and we make it an easy one: we bring the conflicts to the surface, show you where each field is written and by whom, and build the sync once the direction is settled. Settling it first is what keeps the sync from spreading the disagreement faster.

Is this the same as EDI?

Related, but not the same job. EDI is integration with your trading partners over X12 or EDIFACT, with routing guides, certification cycles, and chargebacks attached — that has its own page, and it is deeper water. This page is about your internal systems and the SaaS tools you already own. If the work is WMS, TMS, or 3PL-specific, the logistics systems page is the better starting point. Plenty of projects touch all three.

How would we know an interface broke?

Because something told you, rather than a customer. Every interface we build gets a heartbeat, a record of what it processed, and alerting on both failure and suspicious silence — a feed that normally carries two hundred orders and today carries none is also a failure. Messages that cannot be processed land in a dead-letter queue you can inspect and replay, and the replay is documented so your own team can do it without calling us.

From the case files

How this runs in production

Platform · Multi-year build

One application that replaced a decade of spreadsheets

A warehouse ran its floor on shared spreadsheets, emailed reports, and tribal knowledge. We replaced all of it with a single internal platform — and kept it running while people worked.
Integration · Inbound logistics

Knowing where inbound freight actually is

Inbound shipments were tracked by opening carrier websites one tab at a time. We replaced the tabs with live carrier integrations and a workflow that routes exceptions to the person who can fix them.
Automation · Warehouse systems

Automating a system that has no API

The warehouse platform offered no write interface, so every transaction went in by hand. We automated the screens themselves — carefully enough to trust with live inventory.
Get in touch

Which two systems are your people connecting by hand?

Describe the handoff — what gets re-keyed, from where, to where. You'll get back the shape of the interface, what building it involves, and whether a nightly file would have done the job.

Prefer to talk?

Call 832-598-8234 or email msco@stoneagesoftware.com. Houston, Texas — serving Houston, The Woodlands, Conroe, Sugar Land, Katy, Pearland, and the Greater Houston metro.

What happens next

We read your message, an engineer replies with questions or a straight answer, and if a call would help, we book one. From the first reply on, you're talking to the people who'd do the work.

No obligation — we reply within one business day. This form sends your details to Stone Age Software LLC so we can respond to you. See our privacy policy for how we handle them. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.