Technologies

Integration Technologies We Build With

The value of business systems is unlocked when they connect. One Stop Software uses proven integration technologies to make ERP, CRM, and the tools around them share data reliably — entered once, trusted everywhere.

Our work centers on clean, maintainable connections: clear sources of truth, careful data mapping, and integrations built to retry and recover rather than silently drop data.

Core Technologies

Connected Business Systems

One Stop Software connects business software with APIs, ETL, identity, and automation so data flows once and cleanly. Read our business systems insights or start a conversation.

Batch or Event: A Business Question in Technical Clothing

Nightly batch and event-driven sync get presented as an engineering preference. They are really a decision about how wrong you can afford to be, and for how long. If a salesperson closes a deal in the afternoon and the warehouse has to pick it that evening, a nightly job is the wrong answer. If a customer address changes and finance uses it at month end, a nightly job is fine and easier to run and reason about.

Ask the question per data flow. A mixed design is normal and defensible: the urgent flows move immediately, the rest catches up overnight.

Native Connector, Integration Platform, or Custom Code

A vendor’s own connector is the quickest route when it covers your case, and you accept its opinion about how the data should map. An integration platform gives you somewhere to see runs, retries and errors without building that yourself, and it adds a subscription and a skill your team has to keep. Custom code fits when the logic is actually yours and no product models it.

These are not exclusive; one stack can hold all three. What matters is that every connection has a named owner and a place where its failures become visible to a human being.

Matching Rules Are the Real Work

Entering data once and trusting it everywhere sounds like a wiring problem. In practice it is a matching problem. Is Acme Holdings the same company as ACME Holdings LLC and the site record called Acme, Building 2? Do you match on email, domain, tax ID, an external key you control, or a combination with a review queue for the uncertain cases?

Decide the key before anyone writes a connector. Where a stable identifier does not exist, create one and push it into both systems so future syncs have something durable to hold onto. Merging duplicates after the fact is slow work, and parts of it are never fully reversible.

What Happens When an Integration Fails

Integrations fail. A credential expires, an API changes, a record arrives carrying a field the other system rejects. The design questions are whether the failure is visible, whether the message is held for retry or lost, and who gets told. Silent failure is the one that hurts, because the number keeps rendering and is simply no longer true.

Worth insisting on from anyone building your integrations:

  • Failed messages are queued and replayable, so a fix does not mean re-keying by hand
  • Retries back off instead of hammering a system that is already struggling
  • The same message arriving twice does not create two invoices
  • Someone specific receives the alert, and the alert names the flow and the record
  • There is a log a non-developer can read when a customer asks what happened to their order

Test With the Records That Cause Trouble

A test set built from clean records proves the happy path and nothing else. Build it from the records that have historically caused arguments in your business: the credit memo, the order cancelled after partial shipment, the invoice with a negative line, the job number entered with a trailing space, the account whose legal name has changed twice.

Keep that set somewhere the next person can find it, and run it before a change goes out rather than after a customer notices. It costs an afternoon to assemble and it is the difference between knowing an integration still works and assuming it does.

Identity Is an Offboarding Problem

Single sign-on gets sold on convenience. The stronger argument is what happens when somebody leaves. Without central identity, removing access means remembering every system that person touched, and forgetting one is how a departed employee keeps a working login to a system holding customer data.

Centralized identity turns that into a single action with an audit trail, and it gives you a straight answer when a client asks how access to their data is controlled. How these choices land in a specific stack is covered under CRM and ERP Integration, and the Platforms page covers how to evaluate the systems on either end of a connection.