Network
Map shared connections and surface the strongest warm-intro paths
Map shared connections and surface the strongest warm-intro paths
A network is a group of people your organization knows personally — board members, major donors, advisors, alumni, staff. When you add someone to a network, we automatically find every other donor in our database who shares a meaningful relationship with that person: same nonprofit board, same employer, same school, same donation recipient, and more.
These discovered relationships are called connections. Each connection has a strength score from 0 to 1, based on how likely the two people actually know each other — factoring in things like how long they overlapped, how large the organization is, and how recent the relationship is. When we save connections to your networks, we’ve already filtered out the fluff — only connections with a strength of 0.45 or higher are kept. Weaker signals aren’t worth your time, so we exclude them upfront.
You can create as many networks as you need. Common examples:
A donor can belong to any number of networks simultaneously. Adding someone to “My Board” doesn’t remove them from “Advisory Council.”
There are two ways to add donors to a network:
Add a single member — POST /networks/{network_id}/members. Synchronous. Connection computation happens immediately and the response tells you it’s done. Use this when adding one person at a time.
Add members in bulk — POST /networks/{network_id}/members/batch. Asynchronous. Submit up to 100 donor IDs, get back a job ID, then poll GET /networks/jobs/{job_id} until it’s complete. Use this when populating a network with a list.
Connection computation takes a few seconds per donor — we’re searching across millions of records to find shared relationships. The bulk endpoint handles this in the background so you don’t have to wait.
Once your network has members, there are three ways to use it:
POST /networks/discover
This searches our entire donor database for prospects connected to your network members, ranked by connection strength. It’s open-ended discovery — you’re asking “who should we be talking to that we don’t already know about?”
You can scope the search by:
in_network_donor_ids) — only show connections through these peoplenetwork_ids) — only consider members of these networksmin_strength) — defaults to 0.45, which is the lowest stored strength. Connections below 0.45 represent relationships too weak to be actionable, so we don’t store them. Set higher (e.g., 0.7) to see only the strongest connections.If you already have a list of prospects and want to check them against your network, use “Compare prospects” instead.
POST /networks/connections
Submit a list of donor IDs — these are your prospects. We check each one against your network members and return them ranked by connection strength. Prospects with no connections are included at the bottom with a strength of 0.
This is the targeted version of discovery. You already know who you want to evaluate — you just want to know which ones have warm paths in through your network.
You can scope by the same filters: specific members, specific networks, and minimum strength.
GET /networks/donors/{donor_id}/connections
Deep dive on one person’s connections to your network. Returns whether they’re in your network, which networks they belong to, and every connection to your network members. Use this when you’re researching a specific prospect.
POST /networks/lookup
Compute connections for any donor at query time, without needing to add them to a network first. We search across the entire database for people who share meaningful relationships with the queried donor. Results are ranked by connection strength, strongest first. This is useful for one-off research before deciding whether to add someone to a network.
This endpoint can take up to 20 seconds depending on how many affiliations the donor has — we’re computing connections in real time rather than using pre-computed results.
The discover, compare, and donor connections endpoints accept network_ids and in_network_donor_ids as optional filters. Here’s how they combine:
Every connection returned by the API includes:
nonprofit, company, or schoolsits_on_board_of, works_for, donates_to, attends)