About
We built this because the API we relied on went dark
Not suddenly. Over six weeks, from a 0.3% failure rate to 100%, while we read the whole slide as a bug in our own code.
Between June and July 2026 we made 130,220 calls against a third-party enrichment API. It
degraded gradually and then stopped answering entirely, returning 503 with the
body no available server whether or not we sent a valid key. Our own metrics
could not tell us that, because everything that was not a 404 or a
429 collapsed into a single failed bucket.
What survived was the data we had stored. Because we had kept raw payloads rather than only the fields we parsed, we were able to reconstruct a complete field reference from 1,000 person responses and 500 company responses, every field verified against real traffic. That reconstruction is what Triguna's own documentation is built on, and it is why our docs are unusually blunt about parsing traps that a vendor-written reference would quietly omit.
What we decided to do differently
No single source is load-bearing. A record is assembled from several independent sources and merged by documented precedence. If one is unavailable, the record still returns, with fewer fields, and with its provenance intact so you can tell the difference between "no data" and "one source is down".
Provenance ships with every record. source and
fetched_at are not optional metadata. They are the part of the record we can
actually stand behind, and they are what let you defend a decision six months later.
We claim retrieval, not truth. A Triguna record says these sources held this value at this moment. It does not say the value is correct. Every enrichment vendor that implies otherwise is making a claim it cannot support, and we would rather be useful than impressive.
We publish the failure modes. The outcome distributions, the rate-limit analysis, and the parsing traps in the reference are all things it would be commercially easier not to write down. They are also the things that would have saved us months.
What we are not
- Not a search product. You resolve identifiers you already have. There is no path that finds people or companies matching a description.
- Not a data broker with a fixed database. Records are assembled at request time from sources that hold them.
- Not a compliance shortcut. You remain the controller of whatever you retrieve and store. See privacy and data processing.
Talk to us
Technical questions, rate cards, and anything about the data we return: hello@triguna.ai, or use the contact page. Engineering questions reach an engineer.
Read the reference we wish we had
Every field, every parsing trap, and what each status code actually means.