Identifiers and slugs, and what the API accepts

Triguna accepts a LinkedIn slug, a numeric company id, or a full profile URL and extracts the identifier for you. Which keys are safe to store, and what still fails.

Both enrichment endpoints key off LinkedIn identifiers, and both accept a full URL as well as a bare slug. You do not have to write the extraction yourself.

What each endpoint accepts

Endpoint	Accepts	Examples
profile_id	A vanity slug, or any LinkedIn profile URL	williamhgates · https://www.linkedin.com/in/williamhgates/?trk=nav
company_id	A slug, a numeric company id, or a company / school / showcase URL	microsoft · 1035 · https://www.linkedin.com/company/microsoft/about/

Query strings, fragments, and trailing slashes are stripped for you.

# All four of these resolve to the same person.
curl -H "ApiKey: $KEY" ".../v1/people/profile?profile_id=williamhgates"
curl -H "ApiKey: $KEY" ".../v1/people/profile?profile_id=linkedin.com/in/williamhgates"
curl -H "ApiKey: $KEY" \
  --data-urlencode "profile_id=https://www.linkedin.com/in/williamhgates/?trk=nav" -G \
  ".../v1/people/profile"

What still fails

A display name is not an identifier and never will be. Acme Corporation carries no slug, so there is nothing to extract:

HTTP/1.1 400 Bad Request
Content-Type: text/plain

invalid identifier: pass the LinkedIn URL slug (the segment after /in/ or /company/),
not a display name

400 means you sent something unusable. 404 means we looked and there is no such profile. Keeping them apart is the point: one is your bug, the other is reality. Neither is billed.

If your CRM holds company names rather than URLs, you have a resolution problem to solve before you have an enrichment problem. Triguna does not search, so it cannot turn a name into a profile.

Stable keys

Entity	Store this	Do not store this
Person	member_urn	public_identifier, which users can change
Company	company_id	public_identifier, because slugs get renamed

Slugs are user-editable. Someone renames their profile, your nightly job stops matching, and the failure looks like a data-quality problem rather than a key problem. Persist the URN or the id and treat the slug or URL as a lookup input only.

Common traps

company_id also accepts a numeric id. Do not assume a non-numeric slug, and do not “clean” numeric-looking identifiers by stripping them.

Detect job changes on company_id, not company_name. Display names drift (ada becomes ada CX), and name comparison produces a steady drip of false positives.

A 404 is never billed, so a bad identifier is cheap but silent. Nothing on your invoice tells you that a fifth of your calls resolve nothing. Log and alert on the not-found rate explicitly.

Instrumenting resolution

Track these separately, because they have different fixes:

Signal	What it means	Fix
400 rate	You are sending values that carry no identifier at all.	Fix the field you read from; you are probably sending display names.
not_found_rate (404)	The identifier parsed but no such profile exists.	Audit where the URLs came from; some will simply be dead.
null_field_rate	The record resolved but sources held little.	Nothing to fix in your client. Adjust expectations downstream.

Collapsing these into one “enrichment failed” metric is the most common instrumentation mistake, and it hides the only ones you can act on.