Company identity
Tickers are not stable identifiers. They are reassigned, they change at a merger
or rebrand, and the same string can mean different issuers in different decades.
The /v1/identity routes expose the mapping between tickers and issuers as
records with validity windows and a named source, rather than as a lookup that
silently returns today's answer.
Two resolution routes
Arche has two routes that take a ticker and give you a company, and they are not interchangeable:
- Name
/v1/edgar/companies:resolve- Type
- identity only
- Description
Returns
cik,ticker,exchangeandas_of, and nothing else. It is the shortest path from a ticker to a CIK, andexchangeis not currently populated on it. Use it inside a retrieval loop where you only need the key.
- Name
/v1/identity/resolve- Type
- full record
- Description
Returns the whole identity record — including
company_name, a populatedexchange, thecompany_idthe modeling routes need, the validity window, and the SEC filing the mapping came from. Use it when you need to show or audit the issuer, not just key off it.
If you are choosing between them and do not have a reason to prefer the first,
use /v1/identity/resolve. The extra fields cost nothing and one of them —
company_id — is required by routes you will reach later.
Resolve a ticker
curl -X GET "https://api.arche.fi/v1/identity/resolve?ticker=MSFT" \
-H "X-Api-Key: $ARCHE_API_KEY" \
-H "X-Request-ID: $(uuidgen)" \
-H "Accept: application/json"
Representative response:
{
"data": {
"as_of_date": "2026-09-20",
"identity": {
"id": "574477d5-0130-5abb-816c-52cd41c4571a",
"company_id": "8f53593d-eae0-458d-9b33-7ed72325dd96",
"cik": "0000789019",
"ticker": "MSFT",
"company_name": "MICROSOFT CORP",
"exchange": "NASDAQ",
"active_from": "2026-07-17",
"active_to": null,
"is_active": true,
"source": "sec:company_submissions",
"source_loaded_at": "2026-07-17T17:47:11Z",
"source_filing_accession": "0001193125-26-380280",
"confidence_score": null
}
}
}
source_filing_accession names the SEC submission the mapping was read from, so
an identity claim is traceable to a document rather than to a vendor list.
Search by name
When you have a name rather than a symbol. The parameter is query, not q —
q is undeclared and would be ignored, returning an unfiltered page:
curl -X GET "https://api.arche.fi/v1/identity/search?query=microsoft&page_size=25" \
-H "X-Api-Key: $ARCHE_API_KEY" \
-H "X-Request-ID: $(uuidgen)" \
-H "Accept: application/json"
Results come back in the standard paginated envelope, each item carrying the same identity record shown above.
List mappings
Every mapping for one ticker, current and historical:
curl -X GET "https://api.arche.fi/v1/identity/tickers/AAPL" \
-H "X-Api-Key: $ARCHE_API_KEY" \
-H "X-Request-ID: $(uuidgen)" \
-H "Accept: application/json"
Every mapping for one issuer — the reverse question, and the one to ask when a company has traded under more than one symbol:
curl -X GET "https://api.arche.fi/v1/identity/companies/0000789019" \
-H "X-Api-Key: $ARCHE_API_KEY" \
-H "X-Request-ID: $(uuidgen)" \
-H "Accept: application/json"
Mapping validity
active_from and active_to bound the window in which Arche observed the
mapping. Read them as exactly that, and not as the dates the ticker began or
stopped trading:
active_fromis when the mapping was first observed in a load, not the listing date. A mapping that has always been true can still carry a recentactive_frombecause that is when the load ran.active_tois set only once a later load showed the mapping had ended. It isnullfor a live mapping.is_activereflects the current state of the mapping.
Do not use active_from as a corporate-history date. It is
provenance for the mapping record, not a fact about the security. For a
point-in-time question about what a ticker meant on a past date, pass
as_of to /v1/edgar/companies:resolve rather than
filtering these windows yourself.
company_id vs cik
Arche uses two company keys and they are not interchangeable:
- Name
cik- Type
- 10-digit string
- Description
The SEC's own identifier, zero-padded. Every
/v1/edgar,/v1/coverageand/v1/fundamentalsroute keys off it.
- Name
company_id- Type
- uuid
- Description
Arche's internal company key. The
/v1/modelingand/v1/airoutes key off this one instead, and will not accept a CIK.
/v1/identity/resolve returns both, which makes it the natural first call in a
pipeline that will touch modeling later. company_id is null
when the filer is not in the company reference, so check it before passing it on.