This is the tool for questions about a list of people: filtering a list by connection count or seniority, labelling who works where, or filling in headlines before drafting. experience carries every role with its dates, so it also answers career-history questions — how long someone has been in seat, where they worked before, whether they were promoted internally, who is an alum of a given company — without a separate lookup. It does not touch the user's LinkedIn account, so it neither consumes their daily profile-lookup budget nor carries any account-safety risk — prefer it over per-person lookups whenever you have more than a couple of people to enrich.

Costs 0.1 Sliq credits per profile returned; misses are free. A profile this user enriched in the last 24h is served from cache, so re-calling does not look up or charge again.

Enriching a profile also links it to its primary employer's canonical company, which may need a one-time web-domain lookup: 0.05 credits the first time a given company is looked up (cached after, so it never charges twice for the same company). A batch spanning many unfamiliar employers costs a little beyond the per-profile total; fold that into any estimate you give the user.

How many to run is a spend question: run a list of up to 500 straight away. Past 500, tell the user how many profiles it is and what that costs — the count times 0.1 credits — and wait for a go-ahead before running it; a batch that size also takes several minutes, so say so in the same breath. In a background run there is nobody to ask, so run it and report the spend in your summary.

How to call it is a separate question, and the answer is almost always run_code. A direct return is truncated at 50KB, and one senior profile's career history can be a third of that on its own — so a direct call on a dozen executives shows you two of them, after charging for all twelve, since credits are spent inside the tool before anything is truncated. Only a handful of profiles fit. From run_code nothing is truncated: the rows stay in the sandbox and you print only the filter, count, or summary you need. Call it directly only for a few people whose full profiles you intend to read.

What it cannot tell you: whether the user is already connected to someone, their network distance, or shared connections. Those describe the user's own relationship to the profile and only a LinkedIn-account lookup can answer them — use setup_linkedin_sequence(action_type='resolve') when the decision genuinely depends on connection status. One entry per input, in input order — either a profile dict, or an {'error': ...} entry for a profile that could not be resolved. The error says which case it is: no profile exists for the identifier, or the lookup did not finish and the identifier should be retried.

experience and education cover the person's whole history and are long for senior people — a 25-year career can run 20+ roles. They arrive in LinkedIn's display order, which is NOT sorted by date: roles at the same employer sit next to each other, so the first entry is not reliably the current one. Sort on start_date.get('year') when you need chronology. Consecutive entries at one employer are usually one tenure with internal promotions, but check the dates before saying so — a gap between them means they left and came back, which is a different story to tell. Dates are {'year': 2014, 'month': 'Feb', 'text': 'Feb 2014'}; month is missing when LinkedIn shows only a year, and a date can be empty entirely, so reach for .get() rather than indexing. An end_date of {'text': 'Present'} means the role is current, and someone can hold several at once.