Adding custom fields with php-sdk failing

Go to solution

Adding custom fields with php-sdk failing

I need to populate about six custom fields for each contact add so that when that contact is mailed those fields are available to insert into the email text.


This is what I'm doing...


            $field = new CustomField();

            $field->name = "CustomField0";

            $field->value = "testing";




            $contact = $response->results[0];


            $contact->first_name = $fname;

            $contact->last_name = $lname;


            $returnContact = $cc->updateContact(ACCESS_TOKEN, $contact);


This is what I'm getting...    Note that it doesn't matter if I change the 0 to "00" or "01" -- the API is rejecting the name of the attribute so as far as I can tell this isn't working:


Ctct\Components\Contacts\CustomField Object


    [name] => CustomField0

    [value] => testing


Error Updating Contact Array


    [0] => Array


            [error_key] => json.regex.mismatch.custom_fields

            [error_message] => #/custom_fields/0/name: This attribute value must be of the format 'CustomFieldNN'





I'm a little concerned because this post from almost five months ago suggests the solution is to "not use" the Custom Fields.   What is the point of having custom fields if you can't manipulate them via the API when the customer signs up and provides that data?     Is this fixed yet or am I just going about it wrong?



The value must be from 1-15 for that.  Definitely can see how this could be confusing.  Will open up a defect on our side to clean up the error message.  You can see the definitions in our documentation here:

Dave Berard
Senior Product Manager, Constant Contact

View solution in original post


The value must be from 1-15 for that.  Definitely can see how this could be confusing.  Will open up a defect on our side to clean up the error message.  You can see the definitions in our documentation here:

Dave Berard
Senior Product Manager, Constant Contact

This solved my problem but I am beyond frustrated with the interface.   I've had the account for almost a month now and all I've done is play with the API for the sake of automating population of a list and trying to get custom fields to work when I send an email out to recipients.


The custom fields are populating with my test script in a single test user, but of course they are naming themselves "Custom Field 1" through 6.


According to support the reason my emails (to this one test user) are showing up with blank data for the custom fields is because I can't name my custom fields Custom Field 1, 2, 3, 4, 5, 6 -- I have to use names and the solution is to delete all of my custom fields because they introduced a bug by trying to fix the naming of the fields?


what?!?!  So their recommendation?

1. Backup my contacts
2. Delete my custom fields
3. Reimport the backup

So I've tried this.  About 10 times.  Every time I try to import the CSV file I get this:

"We're sorry, but something went wrong.   We've been notified about this issue and we'll take a look at it shortly"

So basically the entire custom field system is broken, you have to jump through hoops to work around known bugs introduced by the designers just to make it work, those hoops don't even work because you can't upload a CSV file to the webpage, and when you call technical support and ask them to assist they say "oh yeah, we have a defect with the custom fields.  We know."


Is this really how Constant Contact operates?  Because I've just about lost all patience with the product and I have not sent one single real email to any subscribers.


Very sorry for the frustrating experience you're having.  Our external API is not able to take advantage of the newer Custom Field functionality at this time as we have not completed our migration of customers.  Because the functionality is not available to all customers and the API would have unpredictable behavior, we have chosen to use a minimum set of supported functionality (custom fields 1-15) that will work in both our older and new contact management solutions.


I'd like to understand more about your inability to insert custom fields.  As of today, I am not aware of any limitations which would prevent you from using the 15 custom fields supported by the API in the same way as custom fields created through the UI.  If you could explain your workflow some more, I'd be more than happy to investigate, understand what the issue is and see if we have a solution, better workaround or at least an explanation for you.

Dave Berard
Senior Product Manager, Constant Contact

Hey Brad,


I wrote a php script to use with Chronoforms which is a Joomla component.  On the website side of the fence I am going to capture the data provided by the end user.  I am making a postal address required to submit that form.


In between the submit key press and interacting with you I take their postal address and geolocate their lat/long coordinates.  Using a second data source I convert the lat/long into a elected official senate and representative district. This takes place in a few fractions of a second and then I do an API call to insert all of the fields into a contact in CC.


I am attempting to insert six fields with each record without issue.  I have a test php script that pushes these values into the record without issue:

house district, rep name, rep phone, senate district, senate name, senate phone


However, they import as the generic names "Custom Field 1" etc.  When I generate a template and try to populate the form with the custom field in the body of the message and email it to the person who has those six fields associated with their entry the email shows up empty / blank.


Andrew Vazquez in support says this:


Unfortunately, the solution to the situation is going to be a relatively labor-intensive process. What happens is that earlier on we experienced an issue where custom fields labeled anything other than Custom Field 1, Custom Field 2, etc., would not function correctly within the system. Custom names for custom fields would not render appropriately. We've since corrected that issue and thereby created the exact opposite situation: any custom field that has the default name will not render correctly. 

You will have to export your data and delete your custom field names from the My settings portion of your account. You will then have to re-import the data with custom fields that are NOT labeled the defaults. You will only have to do this one time. After this, your custom fields will work correctly. 



^ Even if this works I have a sneaking suspicion that the next time my API calls fire they're just going to create new fields named Custom Field 1, 2, 3, etc.  Regardless - I've tried to export the one user I built via the API, rename the fields with english in the .csv, delete all of the custom fields as instructed, and then re-import that CSV.  That re-import fails and crashes with the CSV I just downloaded from the CC website minutes earlier with no descriptive information other than "someone has been notified".  So I've tried to go into the custom fields and just "rename" each field, send a new test email to the one user who has these fields populated and those emails continue to show up blank in the custom area.


I've created new email templates from scratch, I've deleted/re-added over and over again.  I just can't make this work and I'm pulling my hair out.


All I want to do is be able to use the API to populate the custom fields and be able to generate a template that occasionally includes that end-user specific information about the recipient's elected official contact information in the email. 

This really shouldn't be this complicated to pull off but I've hit a dead end.

So I checked with our editor development team.  They did inform me that there were numerous issues with the custom fields in our new contact management system over the past few months that they have been working through.


The good news, last week we released a bunch of fixes for that which the team believes should fix all of the issues you're seeing.  The one issue they are still aware of is that there is a 15m caching delay that can happen if you follow the following flow:


1. Edit a campaign and load the "insert Custom Fields" list to see what is available

2. Import Contacts and/or create a new Custom Field

3. Edit a campaign and load the "insert Custom Fiels" list


At step 1, a cached version of your custom field list is created which lasts for 15m.  So, step 3 would show an inaccurate list for 15m until the cache becomes stale and the data is reloaded.  We are continuing to investigate options for this while monitoring performance of the UI, will update if this changes.


If you still notice any strange or errored behavior, please let me know.  At this point, you should be able to use this process and get full access to all merge fields:


1. Create a bulk import activity using the 15 supported Custom Fields in the API

2. Wait for the import to complete

3. Edit a campaign and insert custom fields

4. Send out the campaign to ensure everything worked as expected (recommed using test list/addresses for first attempt)

Dave Berard
Senior Product Manager, Constant Contact

Regarding issues with adding custom fields using the /contacts method.


After much misery, I can do this. But, just to be absolutely clear: There is absolutely no way to give the "CustomFieldNN" any actual custom name???


This seems to be possible in the UI, but not via API?

You are absolutely correct.  At this time, the UI does support functionality with Custom Fields which the API is not able to take advantage of.  We are researching adding this functionality and what it will mean in terms of changes (if any) to API endpoints now.  Hope to have more news on this in the coming months as we start to bring the new Contact Management System functionality to the API.

Dave Berard
Senior Product Manager, Constant Contact

Its been a year.   Has this been fixed yet?




At this time the API still only supports custom fields using the naming convention CustomFieldNN where NN represents a number between 1 and 15. Adding the option to use and manage Custom Fields that do not fit this naming scheme is part of our ongoing plans to support the new UI features that are not currently in the API.



Elijah G.
API Support Engineer

Unfortunately that was the answer to this question a year ago.   Your API needs to be more agile for such a simplistic task.   Its not like someone is asking you to create a brand new functionality.   Your GUI allows things to be named "Phone"  "street" "CustomerNumber" but the API forces you to use absurd generic naming conventions.


That means the end user has to have a cheat sheet to convert CustomFieldNN to "Street" address when using the custom fields in the body of their email.


The fact that this functionality was promised a year ago, and is being promised again, translates into it is not a priority for Constant Contact API developers and hence we'll be having this discussion in a year.   Or I'll be using a different product.   One of the two.



Certainly understand your frustration here.  I will make sure to pass the feedback on internally.   

Dave Berard
Senior Product Manager, Constant Contact

Pretty crazy this bug was reported two years ago and still there isn't a way to create custom fields on the fly.


Is there a way to add custom fields yet?

Hi Justin - unfortunately this is not a bug.  Today we still do not have the ability to create user defined custom fields in the API and we don't have any expectations on when that functionality will be available through the API.  Appreciate the feedback and will continue to work towards making this happen. 

Dave Berard
Senior Product Manager, Constant Contact

Years later this remains a problem TO THIS DAY

And, whats worse is instead of using V3 to correct that problem ConstantContact just make V3 impossible to use by requiring 3 levels of auth token shenanigans that essentially make the system useless. 


The fix to all of this is to migrate to "a competitor"

I solve this problem by yanking my clients away from ConstantContact and using a system that lets me drop in a simple API Key, a List ID and whatever data I want. Custom fields = no problem. I spend 15 seconds on implementation and the rest of my day is spent doing my REAL job which is web Development and PPC ad management.


Its not our job to debug your broken system.


Any time I come here to ConstantContact I lose HOURS messing with this nonsense. Simple things that should have worked years ago are still a problem. 


For example:

1- NO ONE wants to name their custom fields "CustomField1" and "CustomField2". who would ever want that? What is the point of that?

2- NO ONE wants to generate 3 auth tokens and then set up elaborate CRON jobs and insecure file system URL rewrites to re-generate a Token every 2 hours. I dont even have human words to express how FUBAR V3 of the API is.


Here I am again, years later, faced with the same problems on Constant Contact, explaining to the Client why Constant Contact "not work" and why they need to move.

Hi @ChristianZ825,


As you are aware you have replied to a four year old post. The custom fields can be use with names you designate when using our v3 API.


The oAuth flow in our v3 API uses the same standard oAuth2 protocols that are used in our v2 API. The difference is in order to ensure higher security we have decided to make the Access Tokens expire sooner than the v2 versions.


As far as how to ensure you always have a valid Access Token I'm not sure why you would have elaborate Cron jobs. There are two main thoughts on this. You can capture the error generated when the token expires and then refresh it with a single call which is in Step 5 of the oAuth flow. The other though on this process is to set up a timer and when the timer expires you automatically refresh the token again using Step 5 of the oAuth flow.

Jimmy D.
Tier II API Support Engineer
Developer Portal

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

Visit Page