I’m trying to bootstrap my setup for Infusionsoft so it will create all the custom fields, tabs, and all of that fun stuff that we have in production. I don’t want to have to create all this manually since then I am manually maintaining and trying to keep two different Infusionsoft crms up-to-date with each other. My idea was to just make some code I can run that will update/delete/create all of the stuff I need in the dev environment.
The problem I ran into is that when adding custom fields you need to have a header (which is basically a DataFormTab so I don’t know why it’s not called DataFormTabId) which cannot be created from the API. This means each of my developers that sets up a dev environment needs to manually add all of the tabs in via the UI (which takes precious time away from getting real work done).
I’m requesting that we get write access on top of read access so I can accomplish this. The API functions exist already to do what I want I just don’t have access.
Thanks
The delete for custom fields is not included in the api (xml-rpc or rest) for anyone. There are not different levels of access for you as there are for anyone else. Unfortunately, that ability has been requested for years and has not come. I would not hold out on the idea that you’re going to get it since many have asked for years, it’s not likely to happen any time soon (if at all)
If many paying customers request something and it still hasn’t been done over many years then maybe the company needs to change how they do things.
As a CRM that holds important business data a full featured API is pretty important. It’s sad to see them neglecting theirs (as well as their customers requests).
This alone is a big enough issue to drive me to another product.
It has been asked for but the demand for deleting them is very low and there are some technical design issues they would have to overcome to do it. There production of Keap was there “front burner” project for some time so that also has played a part.
Every product you move to will have something missing that you or someone else wants. My experience is that hopping from crm to crm to find the one that has everything will never work out in the long run because there isn’t a product that has everything…maybe everything that YOU want but someone else would vigorously disagree with you because it didn’t have everything THEY wanted…and so it goes 
In most cases, deleting custom fields with the api is not a high demand issue and that’s generally what they go off of in their production lineup. You can, of course, add your name to those requesting it at https://keap.com/tellus
To clarify: I don’t care about deleting through the API (would be nice though) I want to add items to these tables from the API:
- DataFormTab
- DataFormGroup
In order to create custom fields from the API you need to have a headerId (which is basically the ID of a DataFormGroup). Both of these tables only have read access from the API. This makes what I wanted to accomplish from the API impossible and now requires developers to waste precious time adding the these tables via the UI. I would rather have my developers spend their time doing actual work by making the code do all that for them.
If I can add it through the UI then what issues do they have to overcome for it to be doable from the API? They literally just need to expose whatever code they use in the UI back-end to the API. They already have the logic figured out on the UI side of things.
If the API supported doing everything the UI can do then I don’t see how people would complain about it not doing what they want. I could understand if I was saying cripple the UI and give all the power to the API but that is not what I am saying at all. I just want the API to be brought up to speed with what the UI lets you do so it is actually feature complete.
I honestly just wish Infusionsoft built their UI to interact through the API. That way whatever they add to the UI will just automatically need to be added to the API in order to work. This gives us complete control to do what we want as well as making it easier to maintain (instead of maintaining the UI and API separately).
The other two CRMs that I have experience with from previous employment offered complete support to do everything the UI could do but from the API (cause why not? the logic is all their and built it just needs to be exposed). It’s just really sad to see the Infusionsoft API not really getting any love from the Infusionsoft devs (example: Why is the API fractured into REST/XML and yet the REST API still isn’t feature complete after years?).
In most cases, the “Custom Field” tab and group are already in Infusionsoft. I’ve designed around that premise in the past and it worked out pretty well. The only caveat is that if someone has not created any custom fields yet then it might not exist BUT that can be included as directions for anyone using a product and while it’s not the best user experience, it certainly isn’t a huge issue either…just another thought
“In most cases, the “Custom Field” tab and group are already in Infusionsoft.”
Yeah if your developers are working in the live account the fields may exist. I want my developers working in a sandbox/dev account which they create themselves and will have nothing (basically starting fresh). Working in production is bad practice and is basically what I am trying to phase out. That is why I wanted this done so that bootstrapping a new developer environment is way easier (I don’t even want my developers sharing sandbox instances just so there is less conflicts with data).
You’re basically telling me about the workaround I already know exists (do it through the UI). What I am saying is that isn’t a solution it is just a workaround (they are definitely not the same thing). The API isn’t feature complete and that is a real problem.
Currently I have custom fields on all 6 tables that let you do it. That means every time a developer sets up a new sandbox they have to create 12 records through the UI (6*2 since DataFormTab and DataFormGroup need to be created for each table). This has to be done every time a new developer sets up their instance.
Yes there are workarounds but they are really gross and time consuming. The real solution would be for Infusionsoft to make their API feature complete with the UI. Especially since the code already exists to make it happen it just needs to be exposed via the API.
Infusionsoft just hasn’t been giving their API any love. Like I asked in my previous post:
Why is the API fractured into REST/XML and yet the REST API still isn’t feature complete after years?
As developers move into new territory (serverless, docker, unit/functional tests, new developer practices) the Infusionsoft API needs to evolve.
Long story for why there are the differences but in short:
They intended about five years ago to do away with the RPC.
A couple+ years ago they released the first portions of REST.
Last year they were going to get rid of Infusionsoft and move to Keap only. But the partners insisted that would be a mistake so they later chose to go with both products.
Now, through all the development and internal politics, they’re working with improving things but the above process changed their direction many times in that time period.
I know some of the developers and am on the PAC (product advisory council) and they are now working to add to REST and in fact, we’d been asked what needs to be added to REST and this was one of the things that came up.
So I don’t know the time table for it but updates will be coming.
Thanks for the explanation @John_Borelli
Good to know changes will be in the works. I wish we had some sort of a time table but at least this is better than nothing. I hope at least some changes aren’t more than a year out.