Coverage and limitations
ProfileGlide implements 16 data actions. Each has passed bounded live tests and schema verification against real provider responses and product ledgers. This is implementation evidence, not a claim that the public website/API deployment is complete, every record has all fields, or the complete Edges catalog is supported.
For the feature-by-feature comparison, including every category in the supplied Edges screenshots, read API equivalents and gaps. For concrete integration recipes, read what you can build.
16 actions and their outputs
| Action | Input | Returned record | Credits per record |
|---|---|---|---|
salesnavigator-search-person | First name, last name, current company; optional public profile URL | One matching standard person search row, without a profile visit | 1 |
salesnavigator-search-people | Keywords | People search rows with current role/company, tenure, and IDs | 1 |
salesnavigator-search-company-employees | Company name or ID; optional keywords | Matching employee leads for a specific account | 1 |
salesnavigator-search-company-metrics | Company name or keywords | Total matching results count from search index | 1 |
salesnavigator-search-companies | Keywords | Sales Navigator accounts with headcount band and employee search links | 1 |
linkedin-search-companies | Keywords | Classic LinkedIn company pages with follower counts and handles | 1 |
linkedin-search-schools | Query string | Entity resolution for schools and universities | 1 |
linkedin-search-groups | Query string | Entity resolution for LinkedIn groups | 1 |
linkedin-extract-school-alumnis | School name or ID; optional keywords | Search-visible alumni leads for a school | 1 |
linkedin-extract-group-members | Group ID | Search-visible member leads for a group | 1 |
linkedin-extract-people | Profile URL or supported identifier | Profile with available experience, education, skills, and network counts | 20 |
linkedin-extract-company | Company URL or supported identifier | Company identity, website, industry, source headcount, size range, and locations | 1 |
linkedin-extract-people-post-activity | linkedin_profile_identifier from profile enrichment | Posts and engagement counts | 1 |
linkedin-search-content | Keywords | Matching posts and engagement counts | 1 |
linkedin-extract-post-commenters | Returned social_id | Comments and available commenter context | 1 |
linkedin-extract-post-likers | Returned social_id | Reactions and available reactor context | 1 |
Both /run/live and /run/async use the same action inputs. Live requests can return 202 while waiting for capacity. Poll until terminal; an HTTP 200 can still contain a failed run. Costs apply to returned records, not HTTP requests. Comments/reactions are not unique-person lists or fully enriched profiles. |
What you can build
- CRM research: read a person and company separately; your application maps available fields into the CRM. Profile + company costs 21 credits when both return a record.
- Standard role lookup: match name and current company for 1 credit, without visiting the profile. No match costs zero; ambiguous or incomplete lookups fail without charging.
- Prospect research: collect a keyword-search page, filter it in your application, and enrich selected results. Client-side filtering cannot recover candidates outside the returned page.
- Engagement research: collect posts, then use each
social_idfor comments or reactions. Engagement does not establish purchase intent. - Change alerts: your scheduler makes fresh reads with fresh idempotency keys, stores observations, compares fields, and sends notifications. Missing fields are not proof of a change.
- Managed collection: call the implemented reads without supplying a LinkedIn account or maintaining collection scripts.
CRM connectors, exports, scheduling, snapshot storage, diffs, and notifications are application responsibilities. These compositions are not hosted ProfileGlide workflow features.
Fields and completeness
The implementation projects a selected, documented field set and omits unavailable values. It does not promise Edges' 38/41-field counts or universal field equivalence.
Search returns current job_title, company_name, and tenure_start when present. Full-profile output instead uses experiences[].title, company_name, and date; it has no top-level job_title. Available skills and experience can be truncated, with has_more_skills and has_more_experiences flags. Full-profile connection degree is currently a string; search connection degree is a number. Degree is relative to the managed source account.
Company number_employees is the source's count, distinct from employees_range. It is not independently verified payroll headcount. Company output has singular industry, website/domain, and structured locations; funding rounds, affiliates, follower identities, and distributions are absent. Sales Navigator IDs are not guaranteed on every action's output.
No profile action promises private email addresses, phone numbers, anonymous viewers, every historical role, or access beyond the selected account's visibility. New executions request the source; completed idempotent replays intentionally return their original stored output. Upstream caching and source freshness are not under a blanket “always live” guarantee.
Lists, identifiers, and capacity
Every list is a single source page, capped at 100 results. completeness.has_more is advisory; there is no public continuation cursor or automatic pagination. The standard-person lookup examines at most ten search candidates and returns at most one match.
Use linkedin_profile_identifier from profile enrichment for profile posts. Use the exact social_id from post search/profile posts for comments/reactions. Public handles, numeric member IDs, activity IDs, and social URNs are not interchangeable.
Batch enrichment is a client-managed series of single-person requests, not an array-input endpoint. Limits include 60 requests/minute per workspace, one active run, and at most 20 unfinished runs. Source pacing and daily allowances also apply. A proposed 300,000-credit tier is neither 300,000 full profiles nor a dedicated 300,000-record capacity guarantee.
Expansion paths and account requirements
| Gap | Plausible path | Why it is not equivalent today |
|---|---|---|
| Structured people filters and company search | Sales Navigator structured search and parameter resolution | Public validators, transport allowlists, projections, and quota tests are not implemented |
| Groups, schools, and associated people | Resolve IDs, then Sales Navigator group/school people filters | Search-visible matches are not complete rosters or proof of graduation; access restrictions apply |
| Events and attendees | Exhaust relevant search paths, then native/validated raw reads | Keyword relevance is not attendance; actual event/roster fields need validation |
| Similar companies | Firmographic company search with a defined similarity rule | Not the exact LinkedIn recommendation panel |
| Affiliates | Inspect actual relation evidence; native fields or fixed raw panel read after search investigation | Similarity does not prove affiliation or ownership |
| Funding and company insights | Validate native company response fields after search-path review | Not projected or verified in the current public contract |
| Employee distributions/search metrics | Bounded filtered counts or suitable native insight fields | Search totals can be capped and overlapping; every query must be metered |
| Rich job data | Hiring-related search for company signals; native job search/detail for vacancies | Hiring flags are not detailed job records |
| Viewers/followers/private lists | Relevant identity-scoped filters and authorized native/raw views | Requires the correct customer identity or page-admin permissions; anonymous identities remain unavailable |
| Messages, InMail, invites, follows, inbox | Dedicated customer-connected accounts and validated Unipile operations | No identity onboarding, write quotas, send idempotency, or private inbox lifecycle in this product |
For data reads, prefer Sales Navigator first, then native Unipile, then a fixed raw adapter only for remaining required fields. Provider documentation is a candidate path, not evidence of implemented parity. Rate limits, denied permissions, exhausted quotas, and valid empty results do not justify raw retries to circumvent controls. Netrows is not a backend provider.
Infrastructure and developer tooling gaps
- REST, cURL examples, and OpenAPI 3.0.3 exist. A published TypeScript SDK with retries/pagination does not.
- Idempotency deduplicates one logical request. It is not an automatic provider retry policy; replaying a terminal failure preserves that failure.
- Polling and cancellation exist. Completion callbacks, signed webhook delivery/replays, full pagination, hosted cron, and a workflow engine need implementation.
- A 40 req/s rate, million-record jobs, 1.2s p50/2.4s p99, uptime SLA, SOC 2 audit, selectable regional residency, and 750M/54M coverage are not established for ProfileGlide.
- Product Auth and signup email delivery are configured independently. Public API/web deployment, opening signups, and paid checkout remain launch work.
The roadmap prioritizes structured search/company search, pagination, and richer verified projections, then signed callbacks and scheduling. Customer-connected outreach is a separate expansion with its own authorization and capacity model. Audits and service guarantees require operating evidence, not simply another endpoint.