MAKING THE VENDOR INVISIBLE: THE API'S POWER, OUR FLEXIBILITY

A customer came with a clear requirement: they wanted the activity data coming out of Teramind, but they didn't want anyone internally to be able to answer the question "which platform is this?" Their own reporting team would take it from there, on their own database. Our job was to move the data — not the source.

That one-sentence request actually tested two separate things: was Teramind's API open and flexible enough to technically support this? And could we engineer an architecture that went well beyond a standard deployment, tailored entirely to the customer? The answer to both was yes — and this is the record of that process.

The Teramind side: the power of the API

Beyond its official interface, Teramind exposes a fully-featured REST API that gives you programmatic access to essentially all of the data — user/device-level activity records, agent status, behavior policies, all reachable through endpoints. That means the platform isn't limited to "use the dashboard": you can move the data into your own infrastructure, your own schema, under your own rules. That's exactly what made this case technically possible — without a rich API, there would have been no way to satisfy a "hide the source" requirement at all.

The kymcu side: engineering flexibility

Having the API isn't enough — it has to be wired into the right architecture. The system we built runs in three layers:

1. Pull: User/device-level activity data is pulled from the Teramind API on a regular interval (15 minutes by default).
2. Staging: Data first lands in a SQLite database we fully control — organized as monthly snapshot tables (MMYY_user_all_data) with full historical lineage.
3. Push: The current data from SQLite is pushed to the customer's own MSSQL server via UPSERT (MERGE) — primary key (user, date, program) — TRUNCATE is never used, so there's no risk of data loss.

The only thing visible on the customer's side is a regularly updated user_all_data table. No metadata about the source, no sync-log table, no trace of the tool ever gets written to the customer's database — that's a deliberate architectural choice, a conscious departure from the "log everything" reflex. It's a step beyond a standard Teramind deployment: reshaping the platform around the customer's organizational need.

A real data-loss bug we found

While hardening the system, we found a serious bug in production: the sync query used a WHERE is_active = 1 filter — meaning historical data for any user who left the company or went inactive was silently dropped from every future sync. In an audit/reporting system, that's a real problem: historical records disappearing because a user became inactive is not acceptable.

We removed the filter and started processing all users (active + inactive). Result: tracked users went from 573 to 818 — the historical data for 245 previously-dropped users reappeared and started being preserved going forward.

Incremental sync: a checkpoint instead of a fixed window

The original design re-pulled a fixed window (e.g. "last 30 days") on every run — unnecessary API load, unnecessary reprocessing. We switched to a checkpoint mechanism: on each run, the system reads the last sync timestamp from a sync_metadata table and only pulls data after that point. A fallback lookback window is used only on first install; after that, the system runs fully incrementally.

Verification: comparing the API against the DB

The most dangerous failure mode for a sync system is silently losing data — it doesn't error, it just writes less than it should. To catch that, we built a separate reconciliation tool: for a given date range, it compares daily record counts from the API against what's actually in the database, and produces a color-coded, day-by-day HTML report. Any drift is immediately visible.

Takeaways

• A platform's power isn't limited to its interface. This project was possible because Teramind's API gives you flexibility far beyond the dashboard — a good API is as valuable as the product itself.
• "Standard deployment" isn't always enough. What a customer actually needs is often more than "use the product as-is" — our job is engineering the gap between the two.
• "Hide the source" should be treated as a design principle, not an afterthought. If you don't decide where metadata/log tables live up front, retrofitting "strip this from the customer's DB" later is a much bigger job.
• Filters are the most common cause of silent data loss. An innocent-looking condition like is_active = 1 can quietly erase historical records in an audit-oriented system.
• UPSERT is safer than TRUNCATE+INSERT. Especially in environments where sync runs could overlap, never wipe the target table wholesale.

This case is a good summary of how we work: the right platform (Teramind, with a genuinely rich API) plus the right engineering (an architecture built for the actual need) means the answer to "is this possible?" is almost always yes.