We are able to update this field using XMLRPC. We are not able to read or write it using API. I found this thread from 8 years ago where it was stated these fields were not planned to be included in the Rest API, but XML RPC is being discontinued so this is now required.
If we have to, we would use Keap API v2, too, but we need to figure this out. Any help and/or experience with this is much appreciated!
This field was intentionally not supported in v2 due to security considerations.
That said, I can bring this up with the team so we can re-evaluate whether there’s a safe way to expose it given the XML-RPC retirement timeline.
I also wanted to mention that we don’t recommend migrating from XML-RPC to v1. The recommended path is to move directly to v2 instead, as it is our newest API.
The concern was mainly around exposing sensitive data like passwords, and as part of that same decision the username field was also not exposed in the APIs.
That said, I’ll bring up specifically the possibility of exposing username as part of the Contact object to see if we can revisit this. I’ll keep you posted.
Please and thank you. As you probably understand, we are working against the clock here. We want to make sure we move everything across to the API system from the XML RPC months before expiration so we can have enough time to notice and address any potential bugs that might pop up.
I understand the urgency here and why this is important for your migration timeline.
Could you share a bit more about your specific use case for needing the username field on the Contact object? It would be helpful to understand how you’re currently using it in XML-RPC and what part of your workflow depends on it.
Sure. We have an in house system which allows users to login. Their username often does not match their notification e-mail. We use Keap as a CRM so the primary e-mail is used for notifications. We do not store user passwords in Keap but we do use their usernames.
When the user forgets their password, they request the password reset and they get it to, let’s say johnsemail@example.com. This is their notification e-mail, right? Now, the e-mail also contains information their username is just “johnisgreat” or something like that. They can’t use the notification e-mail to log in and people do tend to forget the username. So, along with the password reset link we give them, we also give them the username reminder.
Meanwhile, I have verified with chat support there are no risks involved here, as we do not use multi-step checkout or customer hub (nor plan to). Our use case seems pretty clean here. We should be able to use it, from where I stand.
Hi @Vuk_X, I discussed this further internally with the team. The concern was not specifically the username field itself, but that historically some integrations built authentication systems around it — for example, using a username/password pair while also treating the username as a foreign key to a Contact record.
From the platform side, that pattern did not serve a strong purpose, especially since the same need could be handled by storing the Contact ID directly in the integrating system or by using a Custom Field on the Contact record for external identifiers.
Because of that, the decision was made not to carry this legacy functionality forward into the newer APIs.
For migrations off XML-RPC, the recommended approach would be:
Store the Contact ID on your side instead of relying on username linkage, or
Create a Custom Field on the Contact record and store the external identifier/username there.
I understand the migration pressure given the XML-RPC retirement timeline, and I appreciate you sharing the details of your implementation and use case.
Thank you for the response, Omar. While it is not what we wanted, it is what we expected. We have already prepared the code to utilize another custom field. We shall be doing it this way going forward. It’s a hassle, but it has to be done.
I appreciate your quick response times and proper attention to the matter.
@Vuk_X, there is another sting in the tail. You will not be able to query by custom field in REST. In other words, if you want to attempt to search the contact by their username that will not be possible either. Alternative solutions would have to be developed.