Determining if a SiteOwner (aka User Name or Account Holder) Exists Under Your Constant Contact Business Partner Account

[CC_TomM]

Constant Contact Business Partners who apply the Constant Contact APIs may want to determine if a specific Constant Contact "User Name" (aka SiteOwner or Account Holder) is contained under their Partner Account.



While there is no direct API to make this kind of a partner hierarchy query, the SiteOwner APIs can be used to answer the question. This posting describes one approach.



The basic approach is to provide the UserName in question to any one of the "SiteOwner APIs" and evaluate the API response. If the UserName is contained in the Partner's account hierarchy, the API will provide a valid response. If the UserName is not in the Partner's hierarchy, the API will return an error.



More specifically:
The API you will need to use is found in theSiteOwner APIs. The API you will need to use is API_GetSiteOwnerID. In order to use this API, you will need to make a GET request to the following URL, substituting the variables explained below:


http://api.constantcontact.com/0.1/API_GetSiteOwnerID.jsp?loginName=&loginPassword=&siteOwnerLoginName=


Parameters:

• - your partner user name
  


• - your partner password
  
• - the site owner's user name you need to test.
  

If the site owner already exists underneath your partner account, you will get a response similar to the following:


0

9999999999999

Status=Open


The 0 is a successful response code. The 999999999999 will be the ID of the site owner and status is the status of the site owner.



If the site owner does NOT exist underneath your partner account, you will get a response like the following:

500

loginName has no access to specified SiteOwner



From this point, your application can decide what to do with this UserName request. You can decide to provide the UserName access to your application or you can prevent it. If appropriate, you may want to send the UserName details to the Constant Contact Business Partner team and request that the account be moved into your account hierarchy (subject to the account ownership and movement restrictions).

[cbaugh]

To make the experience smoother and more automated for the client, more information would really be helpful. Here is our scenario-
We would like to provide integrated access within our products for free for clients that are in our partnership. For clients that are not part of any partnership, we would like them moved to our account. For clients that are with another partnership, we would like to allow them access but for additional billng from their end.

So, if I do the above check, I can automatically allow access in for the accounts that are under our umbrella. I can then store them in a table so I know for reference they are 'approved'.

If we send you an email on the others, we are then in a holding pattern until I hear from you. If I continue to allow access, the clients that from our view point should not have access because they are under another partnership will have access until I hear from you and block.

Solution - If you were to send some sort of code that just told me they were under another 'umbrella'. I don't ned to know which one, just that they are under one. I can then assume for those that are not a match for us and don't return a different code that they will be moved to us and continue to allow access. For those that have the 'other partner' code returned, we can mark them in a table to block access. Then, if they approve the additional billing we can mark it with a different code in the table that they are not in our umbrella but approved for processing.

happy to discuss.. Hopefully not too hard of enhancement. :)

[cbaugh]

On reviewing the code, it seems you may be providing the code ex 500 for the other partner. If you had a generic "no partner" code that would of course work as well.

[CC_TomM]

Thanks for the input Craig.

I understand what you are asking to do and we will consider when we revisit the SiteOwner APIs. However, I want to emphasize that our account policy (per our partner agreement) is that accounts are associated with Partners when the accounts are created. We have a process for correcting accounts which should have been associated with a Partner at creation, but which were accidentally not associated. That process requires a "person in the loop" manual review - so I want to be careful about what is being automated here.


In short, the fact that a customer is not already associated with another partner does not automatically make that customer a candidate to be associated with any specific partner account.