read the key from the customer secret store, never from a prompt or a file in the repo

export STEADYBASE_KEY=$(aws secretsmanager get-secret-value --secret-id <their secret> --query SecretString --output text)

the key is a bearer token. It goes in a header and nowhere else, and it is never logged.

pull the universe once, then poll for changes rather than refetching

curl -s 'https://api.steadybase.io/accounts/bulk?limit=1000' -H 'Authorization: Bearer $STEADYBASE_KEY'

GET /accounts/bulk 404 not deployed today / while that route is not deployed, the same rows are public with no key at /company/data/index.json

join your records on the identifier ladder, strongest rung first: lei, cik, ticker, linkedin, domain, then name with a jurisdiction

join on account_id once resolved; never join on a name alone

a name match without a jurisdiction is how two different companies become one row

send whatever did not join to the resolver and keep the answer it gives

curl -s -X POST 'https://api.steadybase.io/accounts/resolve' -H 'Authorization: Bearer $STEADYBASE_KEY' \
  -H 'Content-Type: application/json' -d '{"identifiers":[{"ticker":"CRM"}]}'

POST /accounts/resolve 404 not deployed today / four answers only: resolved, ambiguous, unresolved, invalid. Do not turn ambiguous into a pick.

subscribe to the triggers that matter to the customer and let hits come to you

define the trigger in words; hits arrive on slack, email or a webhook

every hit carries the quote, the receipt, the clip where one exists, the account_id and your own external id

dedupe on account_id, not on name, ticker or domain

account_id is stable across every surface and survives a rename or a ticker change

a ticker is reused after a delisting; a domain moves; account_id does not