Documentation
What the Triguna enrichment API does
Triguna turns a profile URL or a company URL into one structured record, assembled from independent sources at request time, with source and fetched_at on every record.
On this page
Triguna takes an identifier you already have, a profile URL or a company URL, and returns a normalized record built from several independent sources. You do not search with it and you do not discover entities with it. You resolve a known entity into structured fields.
The API surface
| Endpoint | Method | Returns |
|---|---|---|
| /v1/people/profile | GET | A person record: identity, location, work history, education, skills, badges, and optionally verification and contact details. |
| /v1/companies/details | GET | A company record: identity, headquarters, size, industries, specialities, and funding. |
| /v1/credits | GET | Your remaining credit balance. Free to call. |
Account management, API keys, and billing live behind a separate authenticated API used by the console. Nothing in this reference requires it.
How a record is built
Four steps, in order:
- Normalize. The URL or slug you send is canonicalized into a stable internal identifier. Most integration bugs die here. See identifiers and slugs.
- Retrieve. Independent sources are queried in parallel, each contributing what it holds.
- Merge. Conflicting values are reconciled by documented precedence rules, not by whichever source answered first.
- Return. One record, with response headers describing where it came from and how old it is. See provenance and freshness.
If the upstream provider fails transiently and we hold a stored copy, that copy is served and
marked X-Data-Source: stale_fallback rather than failing your request. Your integration stays up
through a vendor outage for every entity seen before.
What Triguna claims, and what it does not
Triguna claims provenance and retrieval time. It does not claim correctness. A record says “this is what the source held at this moment”, which is a narrower and more defensible statement than “this is true”.
That distinction matters when a record drives a decision in your product. Log X-Data-Source
and X-Fetched-At alongside the decision and “the data was wrong” becomes an answerable question
instead of an argument. See provenance and freshness for how to use them.
When to reach for it
Use Triguna when a person or company record drives something in your product: routing a signup, scoring an account, briefing an agent, populating a CRM. It pays off when the alternative is building and maintaining a retrieval layer yourself.
It is a poor fit when you need to find entities rather than resolve them, when you need per-round funding history rather than the last round, or when you need a guarantee of correctness that no enrichment vendor can honestly give.
Conventions at a glance
| Value | Notes | |
|---|---|---|
| Base URL | https://api.triguna.ai/v1 | |
| Auth | ApiKey: <your-key> | A custom request header, not Authorization: Bearer. |
| Methods | GET only | No endpoint takes a request body. |
| Content type | application/json | Plain text on error. Do not parse failures as JSON. |
| Versioning | Path segment only (/v1) | No version header. |
| Rate limit | 10 requests/second | Per account, adjustable. See the rate-limit headers. |
| Billing | 1 credit per successful record | Errors and not-founds are never billed. |
Full transport detail lives in conventions, errors, and limits.