API Add Contact with Custom Fields - Account Number

SOLVED
Go to solution
BarryB854
Frequent Participant

API Add Contact with Custom Fields - Account Number

Hello,

 

I am trying to upload a contact via the API and I'd like to also add their Account Number during the upload of the contact.  Here is what I've tried with no success:

 

$custF = [];
$custF = ['account_number' => '12345'];

$contact = new Contact();
$contact->addEmail($_POST['email']);
$contact->addList('1285823438');
$contact->addList('1597339570');
$contact->addList('1717557123');
$contact->first_name = $_POST['first_name'];
$contact->last_name = $_POST['last_name'];
$contact->custom_fields($custF);

 

I thought I read it needs to be in an array but that doesn't seem to work. I also tried:

 

$contact->custom_fields->account_number('12345');

and

$contact->account_number('12345');

 

I cannot find any documentation on this as well.

I appreciate any insight.

1 ACCEPTED SOLUTION

Hello,

 

It looks like you're using our SDK, so you don't need to JSON encode your content.

 

You can pass your custom field in by creating a custom field component, setting the values, and then adding it to the contact object.

$customField = new CustomField();
$customField->name = "CustomField1";
$customField->value = "343465";
$contact->addCustomField($customField);

 

Please give this a try and let me know if you're still seeing issues.


Regards,
David B.
Tier II API Support Engineer

View solution in original post

11 REPLIES 11
Jimmy_D
Moderator

Hello @BarryB854,

 

Thank you for reaching out to Constant Contact's API Support.

 

The custom field does need to be in an array. Here is an example of the JSON.

"custom_fields": [
        {
            "name": "CustomField1",
            "value": "Has control of $25 million budget"
        }
    ]

You can find this in our documentation under the Structure section.

https://developer.constantcontact.com/docs/contacts-api/contacts-collection.html?method=POST

 

Please keep in mind that your custom field names need to use the correct naming convention for the v2 API which is listed in the documentation.


Regards,
Jimmy D.
Tier II API Support Engineer
BarryB854
Frequent Participant

Jimmy_D thanks for the response....

 

Would the Keys of the JSON code be the exact name I named my custom fields?  for example:

"custom_fields":[{"name": "Account Number", "value" : "123412"}] 

BarryB854
Frequent Participant

I've read the documentation and created: CustomField1.

 

Then I tried the following JSON arrays. I used your one example and I also tried json_encode(); via PHP.

 

PHP CODE:

$custFPre = ['custom_fields' => ['name' => 'CustomField1', 'value' => '12345']];
$custF = json_encode($custFPre);

JSON From Above:

{"custom_fields":{"name":"CustomField1","value":"12345"}}

Here is what your example I used:

$custF = '"custom_fields": [
                        {
                            "name": "CustomField1",
                            "value": "343465"
                        }
                    ]';

Then my actual PHP calling the contact() object:

$contact = new Contact();
            $contact->addEmail($_POST['email']);
            $contact->addList('1285823438');
            $contact->addList('1597339570');
            $contact->addList('1717557123');
            $contact->first_name = $_POST['first_name'];
            $contact->last_name = $_POST['last_name'];
            $contact->custom_fields = $custF;

This is the error I receive:

Array
(
    [0] => stdClass Object
        (
            [error_key] => json.type.invalid
            [error_message] => #/custom_fields: Value is of a disallowed type. Allowed types are: Array, Null.
        )

)

I appreciate any insight.

Hello,

 

It looks like you're using our SDK, so you don't need to JSON encode your content.

 

You can pass your custom field in by creating a custom field component, setting the values, and then adding it to the contact object.

$customField = new CustomField();
$customField->name = "CustomField1";
$customField->value = "343465";
$contact->addCustomField($customField);

 

Please give this a try and let me know if you're still seeing issues.


Regards,
David B.
Tier II API Support Engineer

View solution in original post

BarryB854
Frequent Participant

That did the trick.


Will that ever be updated with you can use your own naming convention instead of the custom_field_n?

 

Thanks!

Hello,

 

All of our SDK libraries only work in our V2 API. The V2 API can only see and use custom fields that follow a very specific naming convention (such as "Custom Field 1" for example) as it was designed with our older contacts system which did not have support for named custom fields. While it is possible to create custom fields with other naming formats using our website, the V2 API cannot see or interact with custom fields outside of that convention.

 

Our new V3 API does have the ability to work with named custom fields, however we don't have any SDK libraries available for use with our V3 API. But if you are interested in taking a look, you can find the documentation for V3 here:
https://v3.developer.constantcontact.com/index.html

 

Regards,
David B.
Tier II API Support Engineer

ocreations
Regular Participant

The "solution" does not solve the problem.

 

Turns out V3 solves the custom field names...

but V3 is not useful for collecting leads from stable landing pages with signup forms because there are 3 tokens that need to be generated and regenerated every 2-24 hours. When 100-1000's of people are visiting a page "simultaneously" and one is paying for PPC clicks this causes some serious problems as 50% of more of the subscribes are lost, fail, throw errors, take too long to respond, ect...

 

And with V2 well... that SDK showed some promise. (at first)

Turns out naming 10 custom fields "CustomField1" and "CustomField2" ect... defeated the purpose of having custom fields.

V2 is bulky (I believe it could have been written as 1 class in 400 lines instead of 400 files).

 

It's a shame that V2 worked in all other regards...

Hi @ocreations,

 

Our v3 API uses standard oAuth2 protocols and is very easy to implement. You have obviously already read the documentation. Once you go through the initial steps and the Access/Refresh Tokens are generated you can then store those for later use. The Access Token is of course used for making API calls and the Refresh Token is used to go through Step 5 of the oAuth flow when when Access Token expires.

 

Some folks like to automate the refresh process and there are two main ways to do this. One way is to capture the error message that is generated when the Access Token expires and then automatically run through Step 5. The other way is to create a timer that counts the duration of the Access Token. When the timer expires you then go through Step 5.


Regards,
Jimmy D.
Tier II API Support Engineer
ocreations
Regular Participant

It is disappointing that Constant contact has created such a complex roadblock for us to use the V3 system...

To be clear, can you confirm if the following statements are true, false or need disambiguation:

 

In V3 of the API,

  • the only way for us to send custom data
  • from custom forms on our end
  • with custom field names into our Constant Contact list is to:

 

  1. Generate an Oauth Token url using the V3 API
  2. Validate that URL with app permissions
  3. Store the response code 
  4. Send that response code back to your system
  5. Get a TOKEN that will expire either in 2 hours, or, 24 hours
  6. Save that token, and the "refresh token" in a database or a file system
  7. when that token inevitably expires send the "refresh token" back to your API
  8. Store both new token and "refresh token"
  9. repeat 3 through 8 every 2 or 24 hours...
  10. and if something go's wrong, then start at #1 again

And potentially do that for every visit for 1000's of visitors to check if the Token has expired, and if so, then do that again, and again, and again...

Just to add emails, some segmentation data and custom fields into our mailing lists?

 

and... there is no SDK or set of code that does this for us, so we have to write that solution from scratch using the online documentation examples.

and... when that is done, we still need to code up the solution to actually manipulate those lists as well, since our implementation of the V2 SDK  that we have in place does not work with V3?

 

Are all of these statements/assumptions true?

Hi @ocreations,

 

There seems to be some misconception about who the oAuth process is used for and the steps that are needed. The steps you have laid out are incorrect. Let me see if I can clarify how everything should be set up.

 

Your application is going to be a sign-up form that will be placed on your website. The oAuth process will be used for the account that receives data from the sign-up

form. This means the oAuth flow needs to be done only for the single Constant Contact account that gets connected to that sign-up form. The potentially 1000's of people who fill out your sign-up form do not need to go through the oAuth flow.

 

You listed 10 potential steps in the oAuth process when there are actually only 5 and out of those 5 steps only 1 of them ever needs to be repeated.

 

Step 1 of our oAuth documentation is used to put together the URL that will eventually generate your Authorization code.

 

Step 2 doesn't actually have any code on our side. This step is done completely on the developer's side. This is where you take the URL from Step 1 and add it to your application in a way that will direct the user of the sign-up form (remember this will be the Constant Contact account owner, not the people who fill out the form) to a website. They will enter their Constant Contact username/password and click on the Allow button which will give permission to your application to send/receive data to/from their account.

 

Step 3 is where the redirect URI that you set when creating your API Key is used. After the Allow button is clicked in the previous step the user will be directed to your redirect URI. In the address bar of the browser will be your redirect URI along with the Authorization code appended to the end. This is where you need to your application grab that code to be used in the next step.

 

Step 4 is where you take the Authorization code from the previous step and make a POST call to our API. You will exchange the Authorization code for an Access Token and a Refresh Token. You will want to store both of these tokens for later use. You no longer need to store the Authorization code.

 

The above 4 steps only need to occur once for each user of your sign-up form application.

 

Step 5 is the only step that ever needs to be repeated assuming all of the previous steps were done without errors. Once the Access Token expires you will use the Refresh token to make a POST call to our API. This will generate a new Access Token and Refresh Token. You will then want to replace the old Access/Refresh Tokens with the new tokens. Since the Access Token has a maximum life span of 24 hours you will be repeating this step at least once every 24 hours per user. Again please keep in mind the user of your application is the owner of the Constant Contact account that receives the data from the sign-up form and not the people that fill out the sign-up form.


Regards,
Jimmy D.
Tier II API Support Engineer
ocreations
Regular Participant

I understand the process clearly. 

Pleas allow me to convince you this problem is real, and a good solution is not available to us:

Try to build a simple LANDING PAGE in standalone PHP that hooks up to Google Ads. 

3 custom fields for Constant Contact needed: "Project type, Budget, State" 

Add a checkbox that says "subscribe to our mailing list"

 

No database. no CMS. nothing fancy.

Just a PHP form and a landing page.

 

Then,  watch someone try to build it and connect it to V3 of the API

Record that process. Try it your self. Have another developer try it.

 

Don't show them how to do it. Let them try to make sense of the documentation. 

Watch. Listen.

 

I think you will see the areas of improvement needed,

and, why it is impossible to pull this off easily, efficiently and fast.

 

By witnessing other people use this system things will quickly become apparent:

1- improvements to the documentation layer

2- why step 5 is unnecessary (and overly elaborate)


The main challenge we face here is the "renewal" of the token. 

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

YAGNI applies here - a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.

 

Step 5 is not necessary.


To do that we have to involve abstract elements of time, error checking, return error codes, saving the token, saving the time it was created, recreating it, CRON jobs, a database or writing to the file-system. This turns a 3 hour bang up job into weeks of development, writing classes, debugging and even then, the possibility exists that leads can be lost if something go's wrong. 

It's unnecessary for just trying to make a landing page to collect emails don't you think?
We really need a more elegant solution.

Can you look at this problem and do something effective for us?

 

The simple answer is the right one here I think: let us generate and sign a token that does not expire to use our own CC list. 

  • Step 5 is not applicable to us, and does not help us, and is overly elaborate.
  • It does not protect us, nor our data
  • Step 5 is only a roadblock to us being able to use our own system as advertised and intended.

 

In closing:

I urge you to please try to build a simple PHP/HTML landing page that uses the V3 API yourself and watch someone else build one. 

The experience will reveal very important improvements that are desperately needed to make V3 a practical and useful utility. 

Developer Portal

View API documentation, code samples, get your API key.

Visit Page