Legacy Key Sunsetting

API Q&A
1

Good morning!

If you are still relying on our first form of API authentication known as “Legacy Keys” the time has come to update to use one of our more modern methods, either OAuth2 (for third-party integrators) or Service Account Keys (SAKs, for first-party integrators).

If you have any questions, we are providing a live webinar on 6/13/24 at 1PM MST to go over details of the sunsetting.

You can find more information about why we are making this change here:
https://developer.infusionsoft.com/legacy-key-deprecation/

You can find detailed instructions on how to migrate here:
https://developer.infusionsoft.com/legacy-key-migration/

Thank you for integrating with Keap!

2

To Keap,

You do realise that the Legacy API Key has been around since 2006 (18 years), which means that 1000s of scripts would have been developed over the years. I do understand that now-a-days most integrations would be using the new OAuth Connections. But there could be 100s of Scripts / Software out there where people are still using. Some of those may have not been maintained for years, but are still functional.

What would be good to know is what is the percentage of your API Requests that are still being accessed by the Legacy API Keys?

I would like to also point out that other platforms would give a 1 year notice when they deprecate things, your timeline is too short when you have some in use for a long time.

It now also leads to the question about the XML-RPC API, are you planning to sunset that soon?

3 Likes
3
  • Yes we realize there is a lot of old code out there using legacy keys.
  • It is very difficult to answer this due to what does “your” mean. Does it mean a tenant in Keap or an Integrator? Since we have no way to identify different clients that use the same legacy key within a tenant all we can determine is what percentage of API calls to a tenant is OAuth/PAT/SAK vs Legacy Key. Not sure knowing the percentage helps get existing systems migrated though.
  • Legacy Keys have been deprecated for years, and especially since the release of Personal Access Token (PATs) and Service Account Keys (SAKs) we have encouraged developers to move to those which are nearly identical. In fact we imported all legacy keys as SAKs in each tenant. We are at the point we need to sunset them completely.
  • Please take a look at the docs provided and I hope your concerns over the required time to migrate will be eased.
  • XML/RPC has been deprecated and in maintenance mode for years as well. We are actively adding to our v2 REST offerings to get value parity with XML/RPC, so developers won’t have a reason to use XML/RPC. There is no sunset date for XML/RPC at this time.
4

The lack of parity between the REST and XMLRPC is my biggest concern. Right now both REST V1 and V2 lack abilities that the XMLRPC can do, and those requests are imperative for my clients.

5

We understand, but the sunsetting of legacy keys is not related to XML/RPC vs REST. You can use XML/PRC with all our authentication mechanisms.

1 Like
6

@bradb, here is my point of view on things.

Sunsetting Instructions

https://help.keap.com/help/sunsetting-legacy-api-keys

Quote the August 5th date.

  • Aug 5, 2024: - We will begin a series of brownouts (intentional, planned disruptions of service). You will not be able to opt out of these. The only way to avoid them is to complete the migration. These will increase in length as we move closer to the blackout date. We will publish the schedule of times and dates in our regular communication outlets, such as the Keap Community, Integration, and the Keap API Community on Facebook.

I never seen this being done in other platforms that have deprecated API functionality. They usually give a warning 1 year before any changes are done to the service. Then repeat the warnings until the end.

Your timeframe is too short, and you are trying to quickly force developers to make the necessary changes.

I can see some people’s integrations breaking, and some may not be able to easily get it fixed. It depends if the developers are still around, and if they can make changes to the source code as well.

API Requests Question

All your API Requests require a Key (OAuth / PAT / SAK / Legacy Key) to gain access. You do track the API Requests that are made as Log Files can be requested. This means you will be able to know the percentage of API Requests that are being made using the Legacy Keys. it does not matter if the same key is being used.

Service Account Keys

In some of the integrations that I have done, using SAK is an alternative, and changes can be done quickly. Unfortunately, you have imposed lower threshold limits in comparison to the Legacy Key, which require some of the integrations to be changed to OAuth instead.

I also like to point out that SAKs has one security issue which is similar to the Legacy Key. If you create the SAK it is hidden in the UI, which is great. Unfortunately, it does not stop people sharing that Key if they want to.

OAuth

Have you fixed all the quirks with OAuth? When it was initially released, it was not very stable. I know that you have changed providers, so I am wondering if developers are still reporting quirks from it? Some developers over the years have reported issues.

API Domain Name

Infusionsoft was rebranded to Keap, so why is the API Domain Name still uses “infusionsoft.com”?
I will let you think that one over.

REST API

The reason why I asked the XML-RPC question, is that if the REST API becomes more comparable, then how quickly are you going to be deprecating that? If you do it in the same timeframe as like the Legacy Key, then not everyone would have time to make the changes.

Please explain something to us all. In 2016/17 you initially released OAuth, and it showed that Version 1 was completely inadequate. Version 2 is meant to be much better and should be comparable to XML-RPC.

Why after 7+ years the REST API is still not comparable? How many more years will it take?

2 Likes
7

@Pav I will try and answer your questions regarding the migration and timelines, but topics outside of that just derail getting everyone the relevant information.

Timeline

The timeline is the timeline. We had to make a strategic organizational decision that balanced consideration for both customer needs and business requirements. The point of the brownouts is to let customers know there is an issue that they were previously unaware off. We know there is a subset of customers that use legacy keys and don’t even know they use the API. This is a last ditch effort to get the attention of these customers before the legacy keys are turned off permanently. Before any brownouts occur there will be many communication touch points to get customers to take action before they are affected by a brownout (emails to app owners, in-app Pendo notifications, social posts, community posts etc.). Targeted customer communication will be sent to only those who have had Legacy Key usage within a specific timeframe.

SAKs/OAuth:

Unfortunately, you have imposed lower threshold limits in comparison to the Legacy Key, which require some of the integrations to be changed to OAuth instead.

Yes, we have been asking developers for many years to use OAuth if they connect to more than once tenant. The throttles are setup in a way to encourage that.

Have you fixed all the quirks with OAuth?

OAuth has been very stable since we originally released it in 2014. We had 1 outage in the last 10 years around OAuth. In nearly all cases where developers run into quirks and reported issues, it was determined that developers weren’t handling token refreshes safely.

8

This is a quick fix for the original iSDK class.

If you’re using the original iSDK class you need to make make two changes to the code, one is the isdk.php file and the other is the xmlrpc.inc file.

In this isdk.php file you need to update the API URL: (this is on line 56)

//        $this->client = new xmlrpc_client("https://$appname.infusionsoft.com/api/xmlrpc");
        $this->client = new xmlrpc_client('https://api.infusionsoft.com/crm/xmlrpc/v1');

I couldn’t see a way to pass the additional required header so I ended up modifying the xmlrpc.inc file as well in the &sendPayloadCURL() method.

The PAT or SAK is passed as the first param in the $msg object, and you just need to extract it so you can pass it w/ the required header.

This change was in the XMLRPC V3 xmlrpc.inc file:

        // PAT or SAK Key
        $patOrSak = $msg->params[0]->me['string'];
        $headers[] = 'X-Keap-API-Key: ' . $patOrSak;

I have not looked at the XMLRPC V4 code yet.

1 Like
9

@bradb, you do know that some integrations are going to be very niche, and some integrations will be written in other programming languages that are not generally used. Some of your customers will have to pay thousands of dollars to either get it fixed, or have something built to replace it. They will not be happy about it.

What I am concerned about is that you are removing something that has been in use for 18 years in a space of a few months. If you are doing that to the Legacy Key, then what will happen in the future when you plan to sunset the XML-RPC API? Expect everyone to convert to the REST API in 6 months?

Have you done any type of metrics on the number of API Requests using the Legacy Key?
Are you gambling that it will be down to 5% usage by the end of the year?

You need to be monitoring that figure closely, because if it is still above 10% by the end of the year, you need to chase your customers, as it may hurt their business when the Legacy Key disappears.

1 Like
10

@Marion_Dorsett2,

You can make the Legacy iSDK work all the way to PHP v8.3 and the latest XML-RPC API library.

For the XML-RPC v4 library, you need to make a change in the “methodCaller” function.
The “params” property is not exposed anymore.

Change these lines:

    $call = $this->xmlrpc_request($service, $callArray);
    array_unshift($call->params, $this->encKey);

to the following:

    $call = $this->xmlrpc_request($service, array_merge([ $this->encKey ], $callArray));

The iSDK does hold up well for each new PHP version, but small tweaks maybe needed.

3 Likes
11

@bradb, I am going to propose a suggestion to you that may help your customers understand what integrations they have got running on the Legacy Key.

Can you add the ability for your customers to view the API Requests that are using the Legacy Key?

If your customers can see that, they could copy the requests into the community so that people can see what type of API activity is going on. I believe you log identifiers in your requests, which means it maybe possible to work out what integration is being used, or if it is a custom developed script. If that does not help, we could explain what the requests are doing, and it may jog people’s memories on what the integration is doing.

Also, by allowing the customers to see the activity, they can find out that after they have done the necessary changes. When they do not see any more activity, they will know they have transitioned across.

Your brownout plan will help, but it will not be effective with every particular integration, depending on how often it is being used.

13

If we’re using OAuth will we also need to update to the latest PHP SDK?

15

No, OAuth is unaffected.

16

Just getting up to speed on this announcement and trying to help other non-devs navigate this, mostly partners and some Keap customers. I am all for this change, it a huge security risk… but I have some concerns about the comms and timeframe.

My understanding is that on 10 July no new key can be generated. If that is the case then if a key is compromised after that date, the Keap customer will lose their ability to integrate any apps that are using Legacy API key. Or a new customer won’t be able to use any apps that have not yet moved to OAUTH or one of the other options.

That means we have 3 weeks before things start to become real world impacts on partners and customers.

I have suggested elsewhere that Keap provide app owners and all partners connected with the app a list of IPs that have used the Legacy Key for that app int he last say 90 days (just as an example). That way it can help us all work out if they have hidden apps and custom built code that needs to be dealt with. I will find it pretty amazing if you don’t log this info for security reasons alone. That list would be amazingly useful, and apps that don’t have anything touching the legacy API connection we don’t have to waste time worrying the client or looking for apps/code.

Again, I am all for this… but I see some looming problems that are going to cause problems and potentially business damaging problems for Keap customers.

17

I’ve just seen the notification that my system is using API keys that are going to be phased out. Anyway of finding out where they are being used as they are probably something i set up years ago that have totally forgotten about?
Or do I just wait and see what breaks and then try and fix it???

1 Like
18

At this point it would appear to be a “see what breaks” scenario, however, if you have all of your code stored locally, you could do a find for your Legacy API Key in the files, and make a list of those files, and start making the necessary changes.

19

This is the biggest question that nearly all of us will have. The notification we received this morning said “We have identified that this app has traffic from legacy API keys.” So the natural next question would either be “which ones” or “from where?” How can a third party identify which apps are using legacy API keys if Keap refuses to provide that information to paying customers?

1 Like
20

My understanding is that on 10 July no new key can be generated. If that is the case then if a key is compromised after that date, the Keap customer will lose their ability to integrate any apps that are using Legacy API key. Or a new customer won’t be able to use any apps that have not yet moved to OAUTH or one of the other options.

@Mark_Penney If a tenant already has a legacy key they will still be able to rotate the key. For new customers this is true, they will not be able to generate a legacy for these integrations. We are not expecting this to big a change to integrators to change the domain they are using and adding the required header. The existing legacy keys have been imported into our API proxy as Service Account Keys and will work until 2025. We are asking everyone to generate new PAT/SAK if they can as they migrate their integrations, but for 3rd party integrators it may not be easy to do that within the given timeframe. That is why we imported the existing legacy keys. It will give integrators the extra time to move to OAuth.

I have suggested elsewhere that Keap provide app owners and all partners connected with the app a list of IPs that have used the Legacy Key for that app int he last say 90 days (just as an example). That way it can help us all work out if they have hidden apps and custom built code that needs to be dealt with. I will find it pretty amazing if you don’t log this info for security reasons alone. That list would be amazingly useful, and apps that don’t have anything touching the legacy API connection we don’t have to waste time worrying the client or looking for apps/code.

We have various different logs. Some give us information about if a legacy is being using, others give basic access log information like IPs, user agents, etc. They are not correlated in any way, and therefore not easy to put together for a user to consume. We have asked folks if they continue to get communications that they are using legacy keys and are not aware of what is the source then to reach out to our API support and we can manually pull some data for them. @Kate_Hills this should answer your question as well.

21

How do I reach out to API support as this is all totally gobbledigook to me :stuck_out_tongue_winking_eye:
Is this something to do with my Zapier integration?