# Pearch.ai API Docs Documentation > Documentation for Pearch.ai API Docs ## API Reference - [Get account information](https://apidocs.pearch.ai/reference/get_v1-user.md): Retrieve information about the authenticated user including their account details, remaining credits, and current pricing configuration for different operations. This endpoint provides: - User account information (email, API key details) - Current credit balance - Pricing details for all available operations with descriptions **Cost: 0 credits** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Get API call history](https://apidocs.pearch.ai/reference/v1-api-call-history.md): Retrieve the API call history for the authenticated user. Returns a list of previous API calls including their parameters, results, and metadata. This endpoint returns history for the following endpoints: - `/v1/search` - `/v2/search` - `/v2/search/submit` - `/v2/search_company_leads` **Cost: 0 credits** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Enrich profile](https://apidocs.pearch.ai/reference/get_v1-profile.md): - Test this endpoint in the [playground](https://chat.pearch.ai/api-enrichment) - Check out official [Python client](https://github.com/Pearch-ai/pearch-client) Retrieve enriched user profile based on the provided Linkedin profile ID or email address as a query parameter. Linkedin profile ID is the part that comes after `https://www.linkedin.com/in/` in the profile URL. You can provide `docid` (LinkedIn profile ID) or `email`. If only `email` is provided, the system will attempt to resolve it to a LinkedIn profile. **Cost: 1 credit + extra credits for each of `high_freshness`, `reveal_emails`, `reveal_phones` and `with_profile` parameters if enabled. `reveal_emails` and `reveal_phones` are 6 credits each when contact data is found. Email lookup adds +1 credit.** **Rate limit: 60 requests per user per 60 seconds.** When the rate limit is exceeded, the API returns HTTP 429 with details about the triggered window, current value, and limit. - [List jobs](https://apidocs.pearch.ai/reference/get_v1-list-jobs.md): Retrieve a list of all jobs currently indexed for the authenticated user. This endpoint returns job metadata including job IDs, descriptions, and creation timestamps. The results are ordered by creation date (most recent first) and can be limited using the `limit` parameter. **Cost: 0 credits** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Delete jobs](https://apidocs.pearch.ai/reference/post_v1-delete-jobs.md): Delete specific jobs from the user's job index by providing a list of job IDs. This operation permanently removes the specified jobs from your index. **Cost: 0 credits** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Find relevant jobs](https://apidocs.pearch.ai/reference/post_v1-find-matching-jobs.md): Accepts a profile (arbitrary JSON), and returns a list of jobs relevant to the provided profile. This endpoint is used in conjunction with `/v1/find_matching_jobs` endpoint. 1. First you need to upsert jobs with [/v1/upsert_jobs](/reference/post_v1-upsert-jobs) 2. Then you can use [/v1/find_matching_jobs](/reference/post_v1-find-matching-jobs) to find jobs relevant to a profile. **Cost: 1 credit per found job** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Index jobs](https://apidocs.pearch.ai/reference/post_v1-upsert-jobs.md): Accepts a JSON array of job objects, each with `job_id` and `job_description` fields, and adds them to a custom index. Each account can have a single custom index only. This endpoint is used in conjunction with `/v1/find_matching_jobs` endpoint. 1. First you need to upsert jobs with [/v1/upsert_jobs](/reference/post_v1-upsert-jobs) 2. Then you can use [/v1/find_matching_jobs](/reference/post_v1-find-matching-jobs) to find jobs relevant to a profile. **Cost: 1 credit per job** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Get thread state](https://apidocs.pearch.ai/reference/get_threads_thread_id_state.md): Retrieve the current state of a thread. This endpoint returns the thread's state values, metadata, and checkpoint information. This endpoint is LangGraph API compatible with LangGraph SDK. See LangSmith API definition: https://docs.langchain.com/langsmith/agent-server-api/threads/get-thread-state If the thread is not found, an empty state is returned. - [Search and stream output](https://apidocs.pearch.ai/reference/post_threads_thread_id_runs.md): Create a new run for a thread and stream the output as Server-Sent Events (SSE). This endpoint executes a search query within a thread context and streams the results in real-time. This API is a LangGraph API compatible with LangGraph SDK. API definition: https://docs.langchain.com/langsmith/agent-server-api/thread-runs/create-run-stream-output Official TypeScript implementation: https://github.com/langchain-ai/langgraphjs/blob/main/libs/langgraph-api/src/api/runs.mts#L354-L392 The endpoint supports multiple streaming modes: - `updates`: Stream updates as they occur in the graph execution - `values`: Stream the current state values after each update - `custom`: Stream custom events The response is a Server-Sent Events (SSE) stream with `text/event-stream` content type. Each event contains the stream mode and data. **Cost: (number of profiles returned) × (credits for `type` + `insights` + `high_freshness` + `reveal_emails` + `reveal_phones`).** Example request (Python): ```python from langgraph_sdk import get_client headers = {"Authorization": f"Bearer {API_KEY}"} client = get_client(url=base_url, headers=headers) thread_id = str(uuid.uuid4()) input_data = { "messages": [ { "type": "human", "content": "ml engineers in seattle" } ], } chunks_received = [] stream_mode = ["updates", "values", "custom"] print(f"Starting stream. {thread_id=} {input_data=}") async for chunk in client.runs.stream( thread_id=thread_id, assistant_id="agent", input=input_data, config={}, stream_mode=stream_mode, ): chunks_received.append(chunk) print(chunk) ``` Example output: https://gist.github.com/vslaykovsky/419c9e8348cab643fa8814f2eb6ad120 - [Search companies and leads](https://apidocs.pearch.ai/reference/post_v2-search-company-leads.md): - Test this endpoint in the [playground](https://chat.pearch.ai/api-leads-search/new) - Check out official [Python client](https://github.com/Pearch-ai/pearch-client) Endpoint for finding companies and related leads within those companies. Primary use case is for B2B sales, but can also be used for headhunting/executive search. It uses natural language query and returns a list of most relevant companies. Allows for generation of personalized outreach messages for the identified leads. Main difference with [/v2/search](/reference/post_v2-search) is that the search starts with shortlisting relevant companies first, then finding leads who necessarily activaly work at these companies. Some recipes: - When you only need companies, pass only the company query: `{"company_query": "manufacturers of aviation parts"}` - When you need companies and leads, pass both company and lead queries. Note that the lead query shouldn't include company requirements: `{"company_query": "manufacturers of aviation parts", "lead_query": "CTOs and engineering managers"}` - When you want to generate personalized outreach messages for the identified leads, pass the outreach message instruction: `{"company_query": "manufacturers of aviation parts", "lead_query": "CTOs and engineering managers", "outreach_message_instruction": "Suggest buying my (Rob) SaaS recruitment product <300 characters, email style, casual, personal touch"}` - if you don't have good intuition about leads to target, use a very broad lead query like `{..., "lead_query": "people who I can contact regarding partnerships or any c-level (CEO CFO COO CTO CIO CMO CHRO CPO CLO CSO) /founder/director/owner roles"}` **Cost: (number of companies returned) × (5 + `company_high_freshness` if enabled) + (number of leads returned) × (2 + sum of credits for `outreach_message_instruction`, `reveal_emails`, `reveal_phones`, `filter_out_no_emails`, `filter_out_no_phones`, `high_freshness`)** _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Count profiles matching custom filters](https://apidocs.pearch.ai/reference/post_v2-search-count.md): Return an estimated count of profiles that match the provided `custom_filters`. This endpoint does not run the full search pipeline (no LLM query interpretation). It is intended for quickly checking how broad or narrow a set of filters is before running `/v2/search`. The request must include `custom_filters` with at least one non-empty constraint (for example `locations`, `titles`, `companies`, `industries`, follower count ranges, etc.). Expect slower response for expected large counts. E.g. for title="manager" from "US" you should expect slower response and approximate=true in the response. For title="meteorologist" from "tokio" expect faster response and approximate=false in the response. **Cost: 2 credits per call** **Rate limit: 60 requests per user per 60 seconds.** This endpoint shares the same rate limit as actual `/v2/search` and `/v2/search/submit` executions. When the rate limit is exceeded, the API returns HTTP 429 with details about the triggered window, current value, and limit. _Check out official [Python client](https://github.com/Pearch-ai/pearch-client)_ - [Search people profiles](https://apidocs.pearch.ai/reference/post_v2-search.md): - Test this endpoint in the [playground](https://chat.pearch.ai/api-search/new) - Check out official [Python client](https://github.com/Pearch-ai/pearch-client) Run a search query. This accepts a natural language query as `query` parameter along with additional settings. It returns a list of profiles that match the query and orders them by relevance. The query can be: - a simple search query like "software engineer from Ohio" - a more complex query like "Find me engineers in California speaking at least basic english working in software industry with experience at FAANG with 2+ years of experience and at least 500 followers and at least BS degree". - a full JD-style query that describes the ideal candidate in detail along with job description, responsibilities, requirements, etc. If the query is already structured (for example JSON, structured text, or a boolean expression), you have two main options: - Use the query parameter and pass the structured query as is. This is the simplest approach. Pearch.ai will interpret structured parts and priorities written in free-form text (such as “must have” or “very important”). - Use the custom_filters parameter and map some or all structured parts to it. This gives you more control over filtering. Use parameters to control tradeoffs between speed and quality. Here are some recipes: - For highest quality results (30-180 seconds) use pro search with insights and profile scoring enabled: `{"query": "", "type": "pro", "insights": true, "profile_scoring": true}` - For medium to high quality results use "fast" search (<30s). `{"query": "", "type": "fast", "insights": true, "profile_scoring": true}` - If you want to implement pagination, pass the `thread_id` of the previous request to the next request with increased `limit`. Results are generally returned in the order of decreasing relevancy. However, you may notice results with out of order `score` values in some cases especially when requesting large number of results. It should be safe to use stable sorting by `score` field on the client side in this cases. Note that `score` field is only calculated and returned when `profile_scoring=true`. Check out other parameters below to adjust speed vs quality and additional data that can be returned by the endpoint. **Cost: (number of profiles returned) × (credits for `type` + `insights` + `high_freshness` + `reveal_emails` + `reveal_phones`).** **Rate limit: 60 actual search requests per user per 60 seconds.** `/v2/search`, `/v2/search/submit`, and `/v2/search/count` share this limit. Fully cached thread reloads that do not run a new search use a separate higher limit of 120 cached requests per user per 60 seconds. When the rate limit is exceeded, the API returns HTTP 429 with details about the triggered window, current value, and limit.