Move the XML-RPC Sunset to 2027

API Q&A
1

@Angi_Hast

For the past several months your team have been trying to implement the gaps for REST v2. As we are migrating the code across some of us are finding more gaps, issues, and limitations with the endpoints. Your team still need several weeks of development and testing to do the outstanding gaps. But we also need enhancements done as well, which will require further development.

We are now in June, and more likely by the end of August that most of the gaps will have been filled. That only gives us September, October, November and part of December to migrate across. For more complex integrations, that may not be enough time. Due to the limitations of some of the endpoints that have no plans to be updated, it means developers will have to redo things which adds to the time.

Moving the sunset to Summer 2027 would be beneficial.

2

I have to agree w/ @Pav .
Had Keap proven to be ready for 31-Dec sunset, there would be fewer issues. Deficiences arrive at what seems to be a predictable rate,
This project is at a stage of beta testing its changes on the external development community. Such abuse encourages resentment among those who should be your supporters. They sit in discussions whose topic is “Whither our CRM?”

3

It does seem strange that the deadline would be put on us the users to switch to a new version of their API which is not even finished yet. We cannot move our changes into production until all of our functionality is completly moved over and working.

I agree with @Jeffrey_Chimene the burden is put on us right now to essentially beta test the API.

4

Checking the Tracker we have now reached the 100 Gap milestone. Additional enhancements are also needed to make the endpoints helpful as well.

Not sure what the team were thinking when they announced the sunset at the end of last year. Maybe they were hoping no one would report any issues and everyone would just migrate across without incident.

They should have done more analysis work by checking on what is being used in XML-RPC because all the API activity gets logged.

@CG_Dev, I need to mention that some of the endpoints may not be as flexible as XML-RPC. Listing of the Email Templates is one of them, in which they will not implement. I cannot now retrieve the entire list which means I will have to alter the integration to handle it differently, which adds more time to make the transition. In other words, there are knock on effects with this migration.

5

Development on REST v2 needs to stop and be reviewed, because it has gone beyond a joke now.

  • Inconsistencies - There are inconsistencies with Query Parameters, Maximum Page Sizes on some Endpoints, Monetary figures are either Integers or Doubles (Either use in full or divide by 100).

  • Internal Server Errors - Unhelpful errors that do not tell you what the problems are.

  • Issues - Different sets of issues have been reported, could either be down to the data, bugs in the code, etc,

  • Legacy Items Not Progressing - The legacy items in the application should have been migrated years ago, but customers are still using them. This means that some of the REST endpoints have limitations causing another set of issues when migrating across to them.

  • Missing Fields - The Endpoints are not always matching the XML-RPC fields.

Need I say more!!!

6

this

7

I would agree with postponing the XML RPC Sunset to Summer 2027. I never imagined Keap would actually deprecate the XML RPC API since so many customers use it, so I commend your braveness :smiley: However; Keap has always said they would deprecate it one day so I’m fine with this being deprecated.

The timeline is a point we could argue though.

We are already in June and there have been alot of gaps that basically halted my development back since January. I think recently most of those gaps have been filled but not all. Most weren’t even gaps, but basically just things that didn’t work as expected.

SO - I’ve lost 6 months of development time waiting on API updates from Keap.

I would suggest starting the brownuot schedule in Feb 2027 with a deprecation set for June 2027 at the very least.

Thanks,

Casey

8

On top of my last comment - If Keap had not announced such an aggressive timeline earlier this year with brownouts, I would have procastinated for sure LOL

9

An aggressive timeline makes sense if the API was truly matching to xmlrpc. But like you said, with the gaps, you cannot make a full conversion. It essentially cuts down the timeline.

For those of us who take the deadline seriously we are scrambling to report these issues which would otherwise NOT be found or reported unless we take action to come to the forums and post about it. I appreciate those of you in the forums making these posts. We’ve just started our conversion a couple of a weeks ago so I’m sure there is more we have yet to encounter.

11

@OmarAlmonte @Angi_Hast @Tom_Scott
If you guys are going to start deleting posts from @pav, we might as well call a halt right now.
He’s been on the fora for over a decade. If you don’t like what he’s saying, then engage w/him privately.
Stop treating us like spoiled brats.

12

Position on Extending the XML-RPC Sunset Timeline

I have been somewhat on the fence regarding the proposal to extend the XML-RPC sunset date into the summer of 2027. However, after observing the progress that has been made over the past several months, I am increasingly convinced that the current timeline is driving the right behavior across the ecosystem.

If it were not for the urgency created by the existing deadline, I do not believe we would be as far along as we are today in identifying parity gaps, exposing defects, and driving meaningful progress toward a successful REST V2 transition. The pressure of a firm deadline has focused attention, accelerated testing, and surfaced issues that may have otherwise remained undiscovered for much longer.

I fully agree that parity must be achieved before XML-RPC is retired. That is not in question. What I question is whether extending the deadline will actually help us achieve that outcome. My concern is that pushing the date back simply reduces urgency and delays the focused effort that is currently benefiting everyone involved.

From my perspective, ensuring true parity is ultimately Keap’s responsibility. Third-party developers should not be the primary mechanism for discovering missing functionality, validating parity, or identifying critical gaps in the platform. Those are essential responsibilities of the product and engineering teams and should not rest in the hands of the community of developers; that has been and continues to be irresponsible.

While the developer community can and should provide valuable feedback, the burden of achieving a complete and professional transition rests with Keap.

That said, we are where we are today, and I believe everyone involved is working toward the same goal: a successful migration to REST V2. In that environment, I believe a focused and aggressive push is more effective than extending the timeline and prolonging the process.

What we need most is not additional time. What we need is rapid responsiveness from the Keap development team. When bugs are identified or parity gaps are discovered, they should be addressed immediately. Resolution timelines should be measured in hours, not days, not weeks. That level of responsiveness, combined with the current sense of urgency, is what will ultimately drive a successful outcome.

In short, I support continued pressure toward parity and rapid remediation of identified issues. I am not convinced that extending the sunset date will help us get there. I believe a concentrated effort under the current timeline will serve the ecosystem better than prolonging the transition and extending the uncertainty for everyone involved.

My thoughts for what they are worth to support the lively debate.

~Christian

13

@Christian_Wiles
It’s a reasoned response.
My issue is this: Keap has no responsibility to deliver a reliable, available, maintainable, performant API to the customers of those in this discussion who aren’t Thryv employees.
You’re right: this transition to REST from XMLRPC has taken far too long. You’ve seen what a botch V1 is, V2 and its associated SDK is not looking much better.
I think it’s quite likely that those adopting V2 will deploy to production sometime in Q4. Deploying complex software changes during Holiday season is rarely pleasant. Given that V2 has already been announced as correct and complete, it hardly fosters a complacent attitude towards production deployment when we see the current delta between the press release and today’s state.
Let me quite clear: this rewrite is going to require substantial testing of the reliant business processes. It’s going to involve our customers who trust a relationship that’s built on an understanding of their automation requirements.
There are plenty of indications those on this forum understand blackbox testing. The Whitebox testing for some V2 conversions is an addtional requirement that should be considered when contemplating extending the deadline.

14

@Jeffrey_Chimene @Pav

1st of all, it would be good to have @Pav initial post regarding this issue reposted.

2nd of all, @Jeffrey_Chimene I am not sure I understand you when you say that Keap has “no responsibility to deliver…” . I think you mean that it is our responsibility to deliver solution to our customers, not Keap’s responsibility.

Agreed. It IS Keap’s responsibility to deliver stable API. And when they state that it is at full parity, when it is not, then it IS irresponsible. Stated on the website 11.11.2025 below:

11.11.2025 - product-updates/thryv-api-update-full-feature-parity-and-new-sdks-now-available

We’re excited to announce a major step forward in the Thryv developer ecosystem — our v2 REST API has now reached full feature parity with our legacy XMLRPC API. This milestone marks a major advancement in speed, security, and ease of integration for developers building on Thryv’s platform.

@Jeffrey_Chimene I do not debate how this has been handled. What was released on 11.11.2025 was not true.

I do debate the time factor now. If Keap were to 100% be at Parity, 100% proven by July 1st, no errors found, all documentation correct, what would it change for the timing of migrations?

I know this is all painful for us all.

I just don’t want the pressure released so that updates that do need to happen NOW on the Keap developer front are not treated as URGENT.

Team approach. Keep applying the pressure, calling out deficiencies, and hold accountability.

In @OmarAlmonte 's defense, the issues that I have raised have been handled within a relatively reasonable time frame. Not as quickly on some as I would have liked, but they ARE getting handled.

15

Allow me to continue advocating for the extension.

The extension benefits the relationship between you and your customer. It has little to no effect on Keap’s relationship with your customer. While I recogize there are those on this list for whom that is not true, I maintain they are a tail effect.

Keap does not sell access to its API; it sells access to SAAS with a human at the keyboard. That’s the contract between your customer and Keap.

Your contract with your customer involves the V2 and Legacy APIs. The contract between your customer and Keap does not involve the API.
I could be wrong! There may be something in the ToS that involves the API.

Anyway -

Your’s and Keap’s responsibilities to your customer are the same: both involve access to the database.
This commonality is conflicted by the backend design, which is not fit for purpose. It is not built to satisfy the needs of the API and the human at the keyboard.
That is the reason for my earlier comment: because Keap does not sell access to its API, it has no contractual responsibility for the attributes (RAMP) I mentioned earlier. All revenue metrics are based on a human at the keyboard, not the API.

So where does that leave us?

Given the length of the task list, there is no way in this universe that those with deep XMLRPC integration can possibly hope to deploy earlier than Q4.
Keap is close to producing on a cadence (dumping something every few days); which schedule is fundamentally at odds with a fixed sunset.
So why the fixed date? The Legacy API is a cost sink adversely affecting performance of the revenue generator, the cloud database. This is a death march for Keap development. They are compelled to meet that date.

Nevertheless -

By arguing for an extension, I am arguing for the developer and by extension, their mutual customer.`

P.S. I realize the real revenue generator is the subscription model. For that reason, to steal a quote, Keap could be selling violins or bicycles; they happen to sell software

16

@Jeffrey_Chimene I am arguing for the developer and their mutual customer, but from a different perspective.

There has to be momentum building now because the time is coming where the hard deadline will be enforced, if not extended.

It is human nature to work towards deadlines. Parkinson’s Law, states that “work expands so as to fill the time available for its completion.”

My argument is that I do not want a loss of momentum that a potential extension would foster if we let the foot off of the gas.

I’m going to leave it here.

Respectfully.

~Christian

17

I think both are you are basically in agreement, but arguing the approach. We want Keap to address the issues with the API as soon as possible.

But It’s not possible for us to know what the best approach is, we don’t know the inner dealings inside their development team.

It is up to Keap to determine if they can meet the current deadline at their development speed.

18

Let me say that some of us are not happy of what has occurred over the years with the API.

Timeline

Here is a timeline of things.

  • 2006 (?) - XML-RPC API was initially released.
  • 2015 - REST v1 went into design.
  • 2016 - REST v1 was initially released.
  • 2021 - REST v2 was initially released.
  • 2025 July - Announcement of major expansion on REST v2.
  • 2025 November - Announcement made that REST v2 was full feature parity.
  • 2026 - REST v2 is still having ongoing development.
  • 2026 December - End of life for XML-RPC API.
  • 2027 (?) - Expected for REST v1 to be sunset (Next major API change).

@Christian_Wiles, if REST v2 was at the full feature parity, then I would 100% agree that a 1 year transition would have been plenty of time to do it. I think what happened is that when they made the announcement in July last year, whoever was in charge was either told or thought that there was enough functionality to match the XML-RPC.

There are parts of the REST v2 that Keap will not change which is not going to help developers, for example.

  • Custom Fields Querying - No support to be added, unless you use a Saved Search which are a fixed search.
  • Wildcard Support - Partially added, not the same as XML-RPC Wildcard support.

In the post link below, Keap will not change this endpoint. I have an integration that pulls a list of the Templates via the XML-RPC. I will not be able to do that in REST. This will require a change to the integration, making it awkward for the user to get the Email Template ID. Things like this add further development time which is not helpful.
https://integration.keap.com/t/rest-v2-email-list-email-templates/94087/2

The development of REST v2 is also being rushed, as inconsistencies are appearing, and not enough thought is being put into the endpoints. In XML-RPC all the monetary values appear as Decimal Numbers, which is helpful and consistent. On particular REST endpoints the team decided to add the related currency, which i can understand why, with the monetary values appearing as whole numbers as they want to make it flexible for different currencies. Not a problem just usually divide the amount by 100 to get the proper figure for that currency. But when going to other endpoints the monetary values are back to decimal numbers. If you have code relying on the original figures you will have to either divide or not divide the figures adding to further development work.

All of this trouble could have been avoided if the original team looked at the capabilities of XML-RPC and added that functionality into REST v1. Then the REST migration would have been done years ago, instead of taking 10 years.

Last week I raised several posts that were a combination of issues and requests. Now i need several of them to be resolved to be able to continue the migration. How long will it take for Keap to resolve them? Who knows, but that delays me further, and we only have 6 months to go. Some of us have other work to be getting on with and do not want to be dragged down by this migration.

Checking the Tracker today, there is now 12 gaps that are waiting to be reviewed, 5 are currently being tested, and 2 others are in progress. That does not include the recent gaps, other issues, and enhancements that have been raised either. That is going to take Keap several weeks to resolve those, and then it will be the end of summer.

Anyway, we all have different view points on this migration.

19

@Pav @Jeffrey_Chimene @CG_Dev @Casey_Page @OmarAlmonte

After a lengthy conversation with another client this morning, I have to admit that this debate has done exactly what any good debate should do: it has caused me to reconsider my position.

I still believe that urgency creates focus and that deadlines can drive progress. However, I have come to the conclusion that the timeline is secondary to a much more important issue: PARITY.

First, I believe the announcement made on November 11, 2025, stating that REST V2 had reached parity with XML-RPC was inaccurate. If subsequent events have demonstrated that parity was not, in fact, achieved, then I believe the responsible course of action is to acknowledge that openly and retract or clarify the statement. Transparency matters, especially for developers and businesses making long-term architectural decisions based on those communications.

Second, my position on parity has never changed.

Parity means, fundamentally, the state of being equal, equivalent, or evenly matched.

REST V2 should provide all of the functionality currently available through XML-RPC. Developers should not be asked to redesign business processes, remove features, or accept diminished capabilities simply because the migration target is incomplete. V2 should do what XML-RPC does today, completely and reliably.

Third, after further consideration, I support a true one-year migration timeline, but only after parity is genuinely achieved. The migration clock should begin when developers have a complete and production-ready platform to migrate to, not while critical gaps still exist.

I believe this is a reasonable compromise. It gives Keap the opportunity to deliver a complete solution and gives the developer ecosystem the time necessary to migrate responsibly.

At some point, however, the Keap development team needs to step forward and make a clear statement. The community needs transparency regarding the current state of parity, the remaining gaps, the roadmap for closing them, and the timeline that developers can realistically depend upon.

Everyone involved wants the same outcome: a successful transition to REST V2. Open communication, complete parity, and a realistic migration window are the three things that will make that outcome possible.

Thank you to my friends in the development community helping to push progress forward.

~Christian

20

@Christian_Wiles,

I agree with your reply.

From what i have been seeing over the years, Keap had no intention to maintain parity from the very beginning. This is my reply in July 2024 because they did not want to support custom field querying. That makes it painful for developers to migrate across if they rely on that functionality.

Apart from us that are active in the community, I do wonder if the Third Party Vendors have been communicated about the sunset? It was left late when the Legacy API Keys were sunset.

Keap know they have made another mess again.

21

Keap’s XMLRPC API Sunset Article

https://learn.thryv.com/hc/en-us/articles/41277574163469-Keap-s-XMLRPC-API-Sunset

Quote from the the “Who will This Impact” section.

- Internal Devs – ensuring we have viable v2 endpoints to provide value parity for our XMLRPC endpoints

AI explanation below.

Value parity: “Parity” means equality. “Value parity” means that the new system needs to be just as valuable, useful, and capable as the old one. If the old XMLRPC system allowed a user to do 50 different tasks, the new v2 system needs to allow those same 50 tasks.

Reality - Not happening, currently goes against what was mentioned to the public.