It can be done... sort of...
| Code: : |
$retFIELDS = array('Id','FormId','GroupId','Label','Values');
$query = array('Id'=>'%');
$arrTEST = $myApp->dsQuery('DataFormField', 1000, 0, $query, $retFIELDS);
echo ""; print_r($arrTEST); echo "";
|
The only caveat is... to get the actual **field name**, we're still waiting for one more table to be exposed through the API, the same one that was "promised" to me a few months ago.
With the above code, you will see all the custom form **labels**, which you can normally convert to the field name itself by removing all spaces and underscores.
However, if anyone using your Infusionsoft application has made any changes to the custom fields, then all bets are off.
The reason is that Infusionsoft makes backups of those changes and the backups keep the original names whereas the originals get renamed.
It's a very screwy logic but that's the way it's done.
Back to the above code...
If a custom field label comes up more than once, you can be sure that changes were made to the custom field. You can then start counting...
After the first change, your custom field will have been renamed to "customfield0". After the second change, "customfield1". And so on.
The obvious solution would be for Infusionsoft to expose one additional table through the API, which would then enables to look up custom fields but also to **create** them through the API. The method provided for that purpose doesn't work because they forgot to expose that one crucial table.
The sad thing is that this stupid little oversight to which no one will admit and no one will rectify is stopping many features from being implemented through the API. Sad.
They may have already exposed it and I may have to eat crow, but from the documentation available I don't see that change having taken place.
Good luck!
Best,
Bob