bind.co

Recipe: map your network

Show a user everyone they work with, found in their own mail: who each person is, what they are to the user (a client, a vendor, their accountant), how close the relationship is, and when they last spoke. It is the quickest thing to build on bind.co: it needs only the profile and contacts scopes, which every application can request.

Why it matters: your users get their real network on day one, without importing a spreadsheet or typing a contact, and it stays current as they keep emailing.

Scopes: profile:read and contacts:read (or contacts:write, which includes it, to let the user correct what bind.co found). Webhooks: contacts.first_completed, contacts.completed, contacts.suggestion_available, contact_roles.suggestion_available.

1. Know who signed in

curl https://api.bind.co/v1/oauth2/clients/me -H "Authorization: Bearer $ACCESS_TOKEN"

{"user_id": "usr_0b6f6f5e-2a8e-4b7e-9d0c-3c1f2a4b5d6e", "email": "dana@example.com"}

GET /v1/profile/user-profile adds what bind.co learned about the user themselves, such as their title and profession; see Profile.

2. List the people they work with

Once contacts.first_completed arrives, list the contacts, most recent conversation first:

curl "https://api.bind.co/v1/contacts?sort_by=-last_contact&page_size=50" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

{
  "items": [
    {
      "contact_id": "con_3SrGoE2zltj",
      "contact_status": "active",
      "contact_name": {"value": "Dana Ruiz", "bind_inference_confidence": 0.95},
      "contact_primary_email": {"value": "dana@acme.com", "bind_inference_confidence": 0.99},
      "contact_title": {"value": "Controller", "bind_inference_confidence": 0.9},
      "contact_summary": {"value": "Acme's controller; handles the monthly close.", "bind_inference_confidence": 0.84},
      "contact_relationship_strength": {"value": 7, "bind_inference_confidence": 0.7},
      "first_contact": "2024-02-12T15:03:00Z",
      "last_contact": "2026-10-02T18:20:00Z"
    }
  ],
  "total_items": 1, "total_pages": 1, "page_number": 1, "page_size": 50
}

A people screen needs little more: the name, contact_summary (who they are to the user, in a sentence), contact_relationship_strength (1 for weak or recent, 10 for close and long-standing) and last_contact. first_contact and last_contact are the dates of real emails, not estimates. Newsletters and mailing lists are already left out.

3. Group them by role

Roles say what each contact is to the user. One call gives a "my clients" list:

curl "https://api.bind.co/v1/roles?entity_type=CLIENT&entity_stage=ACTIVE" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Each row carries the role (entity_type, entity_stage) and the contact's contact_name, contact_primary_email, first_contact and last_contact. Try entity_type=VENDOR, ACCOUNTANT or INVESTOR, or entity_stage=DORMANT for clients who went quiet. GET /v1/roles/families shows how role types group, such as accountants under vendors.

4. Show who reaches out

Each contact and role also says who wrote first and last: contact_direct_last_contact is when the contact last wrote to the user, user_direct_last_contact when the user last wrote to them. A "waiting on you" list is the contacts whose contact_direct_last_contact is later than their user_direct_last_contact, or set while user_direct_last_contact is null (the user never wrote back). Either date is null when that side never wrote.

5. Let the user correct it (optional, needs contacts:write)

6. Stay current

On contacts.completed, list again: new people appear and stages move. A stored contact_id that starts answering 404 was merged into another contact. The Contacts and roles guide has every rule.

Make it yours