You must log in to the AcceptIO site before you can use AcceptIO fetcher of contacts. Look for the Login item in the site menu, and then return to this page.

Would you like to use your Google contacts as an address book for your email program? That's simple with an email app on your Android phone or when using gmail, but AcceptIO users can also do that with most desktop or web mail applications. That's possible because we provide a bridge between Google's contact protocols and the standard LDAP protocol. LDAP (lightweight directory access protocol) is an industry standard for accessing address books, and it is an option for many popular email programs. LDAP can also be used by other types of applications. For example, some phone systems can use LDAP lookups to supply caller names to go with CallerID numbers, or to make calls by looking up names.

This page that you are currently viewing is for setting up the necessary access controls and permissions so that you can use AcceptIO fetcher of contacts. This is mostly a one-time process:

  1. Log in to the AcceptIO site
  2. Give consent for AcceptIO to access some of your Google data
  3. Use your Google data in your email program or other application (see the section Configure LDAP client apps)

You will be authorizing AcceptIO to access your Google contacts, as well as your own profile details tied to your Google account. (See the section Consent on Google.) We use the profile details to display your Google identity on this page so that you can be sure you've associated your AcceptIO identity with the appropriate Google identity (in case you have multiple Google accounts). In any case, AcceptIO only reads from that information and never modifies it in any way.

Repeating for clarity: AcceptIO does not add, delete, or modify any of your Google contacts or profile data.

There are a few other things you can do from tabs on this page:

  • Manually refresh our local copy of your Google contacts (see the section Refresh your data)
  • Share some of your Google contacts with other AcceptIO users or accept what they have shared to you (see the section Share contact groups)
  • Withdraw consent to access the Google data that you have previously granted. (see the section Consent on Google.)

If you are just getting started, go to the Consent on Google section, and then verify your identity match-up in the Your identities section.

Your identities
This section exists so that you can verify that you have associated the correct Google account with your AcceptIO account. It's easy to make a mistake if you have multiple Google accounts. If you are ever in doubt, you can always check it here.

If you have just arrived here after giving your consent on Google, you may wish to manually refresh our local copy of your contact data (see the section Refresh your data). That's optional, but it may make it easier to understand certain details.

  • Your AcceptIO user identity is unknown until you are logged in at AcceptIO.
  • Your Google identity is unknown until you are logged in at AcceptIO.

Refresh your data
AcceptIO fetcher of contacts normally fetches Google contact data automatically, when you actually try to use it. However, for efficiency, we won't do that fetch if we have done so recently. In the meantime, we consult that previously-fetched data, which we say is "cached" locally. That means you might not see any recent additions or changes you've made to your Google contacts. You can use the button below to cause an immediate refresh of your Google contacts. That will replenish our local cache with your current Google contacts information.

You can do an incremental refresh (recommended), which will just fetch the differences since the last manual or automatic refresh. Or, you can do a full refresh, which will delete currently cached data and re-fetch everything. A full refresh takes longer, and we don't recommend it in general. However, a full refresh might be useful if you are seeing errors reported on this page or if you suspect something isn't quite right. (You should still report any errors, even if a full refresh resolves it for you.)

You can't refresh your data until you are logged in at AcceptIO.

Share contact groups
You can share some or all of your Google contact information with one or more AcceptIO users. What that means is that when they use AcceptIO fetcher of contacts, they will see not only their own Google contacts, but also any of yours that you have shared with them. You are still the owner of those shared contacts, and you can stop sharing at any time. In this section, you can see and edit which contacts you share and with whom.

On the Google contacts web page, you can create labels and attach those labels to any number of your contacts. All of your contacts that have the same particular label are called a "contact group". You can have as many labels as you would like, and you can attach any number of labels (including none) to any Google contact. (Google also defines a handful of "system" labels. For example, if you "star" a contact, Google attaches the label "Starred" to that contact, even though "Starred" does not show up in the list of labels on the Google web page. "Starred" will show up in your list of contact groups at AcceptIO.)

We can't show your contact group sharing until you are logged in at AcceptIO.

At AcceptIO, sharing is based on contact groups that you create by using labels on the Google web page (or any of the pre-defined "system" contact groups that Google provides). For example, if AcceptIO user Alice has a contact group with the label "Ducks and Geese" that Alice wants to share with AcceptIO user Bob, Alice could do so simply by sharing that contact group with Bob on this page. If Alice does not already have a contact group with the right set of contacts for sharing with Bob, Alice could create a new Google label like "Contacts I want to share with Bob", and then Alice could share that new contact group with Bob on this page. (If you are adding new labels or otherwise rearranging your contact group memberships on the Google contacts page, you might have to manually refresh your data to get it show up here without a delay. See Refresh your data. An incremental refresh should be sufficient.)

When a contact group is shared with you, you must explicitly opt-in if you want to accept it. You should not opt-in if you don't recognize the user sharing a contact group with you.

There are a few things to know about your contact group sharing:

  • Unlike most other contacts-related data, your sharing information is strictly local. It is not obtained from Google. When you purge your data at AcceptIO by revoking your Google consent, the sharing information is not deleted. If you want to also delete your sharing information, use the edit button to remove all sharing.
  • You are sharing the contact group. If you add or remove contacts from that group, the users you are sharing with will automatically see those changes reflected in the group memberships.
  • Google allows you to change the value of a label that defines a contact group. That does not adversely affect the sharing of that contact group at AcceptIO. We will see the name change for the contact group and update things accordingly. In other words, you don't have to worry about it. It should work the way you want it to work.
  • We don't validate the AcceptIO user identities that you use in your sharing information. When it comes to actually sharing contact records, only AcceptIO users can use the AcceptIO fetcher of contacts. That allows you to set up sharing a contact group with another AcceptIO user before they actually start using AcceptIO fetcher of contacts. It's still up to you to enter their identities correctly.
  • When you start or stop sharing a contact group with another AcceptIO user, they don't receive any explicit notification about it. However, they will see it "shared by" table when they view this page. You should notify them.
  • The user you are sharing with might have a contact group with the same name as your contact group. In fact, that's guaranteed when it comes to "system" contacts groups. You don't have to worry about it. If Alice shares a contact group named "Friendly ghosts" with Bob, who also has a "Friendly ghosts" contact group, Bob will see entries from both groups when actually looking up contacts. Alice won't see entries from Bob's "Friendly ghosts" contact group unless Bob shares that group with Alice.

Configure LDAP client apps
This section describes how to configure your email or other application to use LDAP. Since you might be referring back to this section from time to time, we'll start off with a table summarizing the particulars specific to AcceptIO fetcher of contacts. That's likely to be different in specifics from information you might be given for using some other LDAP server. Then, we'll provide some explanation of what those items are, and we'll describe how to configure a few actual clients as examples.

Here is that table of configuration items.

LDAP client configuration for AcceptIO fetcher of contacts
Name of the LDAP
Secure LDAP port number636 (the default ldaps port)
Non-secure LDAP port numbernot available
Base DN for contactsou=contacts,o=gcontact
Base DN for contact groupsou=contactgroups,o=gcontact
Bind DN examplemail=This email address is being protected from spambots. You need JavaScript enabled to view it.,ou=users,dc=acceptio,dc=com
where This email address is being protected from spambots. You need JavaScript enabled to view it. is your usual user account at AcceptIO
Bind password********
Use the same password that you use for other things at AcceptIO
LDAP object class for contactsinetOrgPerson
LDAP object class for contact groupsgroupOfUniqueNames

If this is your first exposure to Lightweight Directory Access Protocol (LDAP), you might be surprised to learn how many applications support it as a mechanism for accessing address book information. (It's also used for many other purposes.) The technical details of LDAP are complex, and the jargon is not especially intuitive to the average user. As so often happens, many application authors try to make things friendlier by describing LDAP concepts with alternative terminology. That's well-intentioned, but it leads to inconsistencies among applications.

Here is a brief description of the things you may have to configure for an application. You will see many similarities to things you are used to for browsing web pages, but there are some important differences.

  • Server and port. You will be contacting a particular server where LDAP is running. You will also be using a specific TCP/IP port number, though there are default port numbers for non-secure and secure LDAP connections.
  • Secure or non-secure. Connections to LDAP servers may be encrypted or unencrypted, just as is the case for web pages. Consult the table to see which connection type or types is available for AcceptIO fetcher of contacts.

    In an application, they may refer to secure connections as "ldaps", "encrypted", "secure", or some other term entirely. (Note: If your application asks if you want to use "StartTLS", you should know that AcceptIO fetcher of contacts does not support that security option.) The default port number for secure LDAP connections is 636. The default port number for non-secure LDAP connections is 389. AcceptIO fetcher of contacts might have been configured to use different port numbers.

    If AcceptIO fetcher of contacts has been configured to give you a choice between secure and non-secure connections, you should choose to use secure connections. You will be sending login and password over the connection, and you want to protect them.

  • Contacts and groups. You can use AcceptIO fetcher of contacts to look up individual contacts or groups of contacts. (You can find more explanation of contact groups in the Share contact groups section.) It's less common for applications to understand how to use groups than individual contacts, but some certainly do.

    The information in an LDAP directory is arranged hierarchically. You would not be far wrong in thinking about it the same way you thing about nested folders on your local computer. When your application sends a request to the LDAP server, it has to tell the server where to start looking. The LDAP terminology for that is "base distinguished name" or Base DN. There are different Base DNs for the set of individual contacts and for the set of contact groups. Your application might refer to the starting point as "Base DN", "directory context", or some other term.

  • Login credentials. LDAP refers to the process of logging in (authenticating) as "binding". For technical reasons that aren't that interesting, you can't just give your userid and password in the usual way. Instead, you must present your userid in the form of an LDAP distinguished name. And, because it's used to "bind" the user to a place in the LDAP server's information, it's called a "Bind DN". (Don't mistake it for the similar-sounding "Base DN" described earlier.) If you are not used to LDAP, the format shown in the table above might look quite peculiar. Your application might refer to this in one of many different ways, but you should in any case follow the format shown in the table when you enter your userid.

    The password is a more normal-seeming item. It need not be wrapped in any peculiar LDAP dressing, but it might be referred to as a "bind password". It might be the same as you use for other purposes at AcceptIO, or it might be different. There should be a note in the table to clarify that for you. Your application may offer to save it for you when you are doing the configuration, it may prompt you for it the first time you need to do an LDAP request, or, it may ask you for it every time you do an LDAP request.

  • Object classes. LDAP can return information in various ways, and the LDAP terminology for the type of information returned is "object class". You will not normally have to provide this information when configuring your application, but the values are provided on the off chance that you are asked.

    There are different object classes for individual contacts and contact groups because the forms of information returned are different for each.

examples of specific clients

AcceptIO fetcher of contacts is powered in whole or in part by software from the open source gcontact project.
Local operation of AcceptIO fetcher of contacts is the responsibility of the AcceptIO support contacts.

© 2009-2020 AcceptIO. All Rights Reserved.
Site Terms and Conditions of Use