Keap’s XMLRPC API Sunset: What You Need to Know and How to Prepare

If you’re running integrations with Keap (formerly Infusionsoft) using the XMLRPC API, mark your calendar: December 31, 2026 is the final sunset date. After that, XMLRPC will stop working entirely, and any automations, custom integrations, or third-party tools still relying on it will break.

This isn’t a surprise change—Keap retired XMLRPC API keys back in October 2024, signaling the beginning of this migration. Now, with 100% feature parity achieved in REST v2 as of October 2025, they’re ready to complete the transition. The clock is ticking, and the time to migrate is now.

If you need help making these changes, contact us today for a free quote.

What’s Happening and Why It Matters

XMLRPC is legacy technology. It predates modern web standards, relies on XML over HTTP, and lacks the security, performance, and scalability that today’s integrations demand. Keap’s REST v2 API uses JSON over HTTP, OAuth 2.0 authentication, and resource-based endpoints—everything you’d expect from a modern API built for the long term.

For anyone running automations that pull contact data, trigger campaigns, manage tags, or sync with external systems, this migration is mandatory. REST v2 isn’t just a replacement—it’s an upgrade. Better error handling, clearer documentation, structured responses, and official SDKs in multiple languages. But none of that matters if your integration breaks on January 1, 2027.

The Timeline: What Happens Next

Keap has published a detailed brownout schedule for 2026. Brownouts are temporary, scheduled outages designed to help you identify which parts of your system still depend on XMLRPC. They start short and get progressively longer throughout the year:

• March 10, 2026: 4-hour brownout
• April 9, 2026: 8 hours
• May 11, 2026: 12 hours
• June 17, 2026: 16 hours
• July 9, 2026: 24 hours (full day)
• August 14, 2026: 36 hours
• September 18, 2026: 48 hours (2 days)
• October 30, 2026: 84 hours (3.5 days)
• December 8, 2026: 96 hours (4 days)
• December 31, 2026: Permanent shutdown

These brownouts serve a purpose: they force your integrations to fail in a controlled environment so you can discover dependencies before the final cutoff. You’ll receive in-app notifications 48 hours before each brownout, regardless of what’s shown in the published schedule.

If you absolutely need uninterrupted XMLRPC access during migration planning, you can opt out of brownout testing by contacting Keap’s API team. But they recommend participating—it’s the safest way to validate that your migration is complete.

Understanding the Shift: XMLRPC vs REST v2

The differences between XMLRPC and REST v2 go beyond format. This is a fundamental architectural change.

XMLRPC uses method-based calls. You invoke functions like ContactService.add with XML payloads. REST v2 uses resource-based endpoints. You send a POST request to /v2/contacts with a JSON payload. Same outcome, different structure.

Authentication changes completely. XMLRPC relied on legacy API keys. REST v2 requires OAuth 2.0, which means access tokens that expire and refresh tokens to maintain access. This is more secure—credentials aren’t exposed in requests—but it requires proper token management in your code.

Error handling improves dramatically. XMLRPC returned generic fault messages. REST v2 returns structured JSON errors with HTTP status codes: 400 for bad requests, 401 for unauthorized access, 404 for missing resources, 429 for rate limits, 500 for server errors. You get clear, actionable information about what went wrong.

Performance is better. JSON parsing is faster and less resource-intensive than XML. Responses are lighter, communication is quicker, and the API scales more efficiently.

Documentation is standardized. REST v2 uses the OpenAPI Specification (formerly Swagger), which means you can auto-generate client libraries, explore endpoints interactively, and rely on a single source of truth for all API behavior.

The migration guide published by Keap breaks down these differences in detail, with side-by-side comparisons and practical examples.

If you need help making these changes, contact us today for a free quote.

Step 1: Assess Your Current Integrations

Before you change anything, document everything. Identify every XMLRPC method your integration currently uses. Which parts of your system call these methods? What data do they send and receive? What business processes depend on them?

Keap provides a Python script in their migration guide that scans your codebase recursively, searches for XMLRPC patterns (like data(, DataService, xmlrpc, xml), and exports all matches to a CSV file. The script ignores common dependency folders like node_modules and vendor, handles large files efficiently, and runs multithreaded for speed.

Run that script. Review the output. Build a complete inventory of every XMLRPC dependency in your system. This is your migration checklist.

For each method, note:

• The XMLRPC method name
• The context in which it’s called
• Sample request and response data
• Any downstream processes that rely on the data

This documentation will be critical when mapping XMLRPC methods to REST v2 endpoints.

Step 2: Map XMLRPC Methods to REST v2 Endpoints

Once you know what you’re using, identify the REST v2 equivalents. Keap has published a comprehensive resource mapping guide that lists every commonly used XMLRPC method alongside its corresponding REST v2 endpoint.

The mapping document organizes methods by domain: Affiliates, CRM, Data, E-commerce, File, Invoice, Order, Product, Search, Webform. For each method, you’ll see the operation (Create, Get, List, Update, Delete) and the REST v2 resource you should use.

Not every XMLRPC method has a direct REST v2 equivalent. A small number of endpoints won’t be converted. Keap has published a separate article detailing XMLRPC endpoints not being converted to REST v2, along with recommended alternatives. If you’re using one of those methods, you’ll need to adjust your approach.

When mapping your calls, pay close attention to required fields and data formats. REST v2 may require fields that were optional in XMLRPC, or expect dates in ISO 8601 format instead of Unix timestamps. The full REST v2 API documentation provides details on parameters, expected payloads, and response structures for every endpoint.

Step 3: Refactor Your API Calls

Now comes the actual migration work: replacing XMLRPC requests with REST requests.

REST endpoints are resource-based. Instead of calling a method, you operate on a resource using standard HTTP verbs:

• GET: Read data
• POST: Create data
• PATCH: Update data
• DELETE: Remove data

For example, an XMLRPC call to ContactService.add becomes a POST request to /v2/contacts. The contact data moves from XML format to JSON format. The response comes back as JSON instead of XML.

Here’s a minimal example in PHP:

<?php
require 'vendor/autoload.php';

use GuzzleHttp\Client;

$client = new Client([
    'base_uri' => 'https://api.infusionsoft.com/crm/rest/v2/',
    'headers' => [
        'Authorization' => 'Bearer YOUR_ACCESS_TOKEN',
        'Content-Type' => 'application/json'
    ]
]);

$payload = [
    'given_name' => 'John',
    'family_name' => 'Doe',
    'email_addresses' => [
        ['email' => '[email protected]', 'field_type' => 'EMAIL1']
    ]
];

$response = $client->post('contacts', ['json' => $payload]);
$data = json_decode($response->getBody(), true);

echo "Contact created successfully. ID: " . $data['id'] . PHP_EOL;

This example includes only the required fields (given_name, family_name, and at least one email address). In production, you’ll need proper error handling, logging, and retry logic for transient failures like rate limits or server errors.

REST v2 returns errors as structured JSON messages with HTTP status codes. Your integration should interpret these codes:

Authentication requires OAuth 2.0. You’ll need to obtain an access token and include it in the Authorization header of every request. Access tokens expire, so your integration must handle token refresh automatically. Keap’s OAuth documentation explains the flow in detail.

If you’re building from scratch, consider using one of Keap’s official SDKs. They provide prebuilt tools and libraries for multiple programming languages, automatically generated from the OpenAPI Specification. The Keap SDK GitHub repository has everything you need.

Step 4: Test and Validate

Once you’ve refactored your calls, test everything. Compare responses from your old XMLRPC calls with the new REST responses. Confirm that all required information is returned and correctly structured.

Validate that mandatory fields are populated. Check that data formats (dates, numbers, strings) comply with REST v2 requirements. Test common error scenarios: invalid input, unauthorized requests, missing resources, rate limits, server errors. Make sure failures are handled properly.

Log everything during testing. Capture request and response details. Monitor API usage and performance. Quickly identify discrepancies or unexpected behavior.

Implement automated tests wherever possible. Validate individual components and end-to-end API interactions. This ensures your integration is reliable, maintainable, and ready for production.

The brownout schedule exists specifically for this purpose. When XMLRPC goes offline during a scheduled brownout, your system will fail if it’s still dependent. Use those failures to discover remaining dependencies and fix them before the final cutoff.

If you need help making these changes, contact us today for a free quote.

Best Practices for Long-Term Success

Completing the migration is just the beginning. Follow these practices to keep your REST v2 integration reliable and scalable:

Centralize authentication handling. Manage OAuth tokens in a single location. Simplify refreshing, storage, and reuse across your application.

Handle errors gracefully. Check HTTP status codes, log relevant information, and implement retries for transient errors like rate limits or server issues.

Validate inputs and outputs. Ensure data sent to the API meets required formats and constraints. Verify responses to detect missing or malformed data early.

Implement consistent logging and monitoring. Capture request and response details. Monitor API usage and performance to quickly identify issues before they impact operations.

Design for scalability. Structure your code to handle multiple resources, large datasets, and potential rate limits. Avoid hardcoding values or limiting your integration to a single scenario.

Document your integration. Maintain clear internal documentation describing endpoints used, business rules, and integration logic. This simplifies future maintenance and onboarding for new team members.

Participate in scheduled brownouts. Join Keap’s brownouts throughout 2026. Test your integration under controlled conditions and verify its behavior during temporary service interruptions. This is your safety net.

Don’t abuse the API. Although throttling is handled automatically, excessive requests may impact your integration’s performance or trigger temporary limits. Be respectful of the system.

Resources and Support

Keap has provided comprehensive resources to support this migration:

• REST v2 API Documentation
• Getting Started with OAuth2
• XMLRPC to REST v2 Mapping Guide
• Migration Guide – XMLRPC to v2
• Brownout Schedule for Sunsetting XMLRPC
• Keap SDK GitHub Repository

For questions or guidance during migration, contact Keap’s API Specialist, Omar Almonte, through the Keap Developer Forum.

What Happens If You Don’t Migrate

Let’s be direct: if you don’t migrate by December 31, 2026, your integrations will stop working. Completely. No grace period, no fallback, no emergency access.

Contact syncs will fail. Campaign triggers won’t fire. Tag applications will break. Custom dashboards will go blank. Third-party tools will lose connectivity. Any automation, webhook, or data flow that relies on XMLRPC will cease to function.

The impact depends on how deeply XMLRPC is embedded in your operations. If you’re using it for critical business processes—lead capture, CRM updates, e-commerce transactions, reporting—the consequences will be immediate and severe.

This isn’t a theoretical risk. Keap has been clear about the timeline, provided extensive documentation, scheduled progressive brownouts throughout 2026, and achieved 100% feature parity in REST v2. The tools and resources exist to complete this migration successfully. The only question is whether you’ll prioritize it before the deadline.

Take Action Now

You have 13 months from the time customer communications began in December 2025 until the final sunset on December 31, 2026. That sounds like a long time, but migration projects always take longer than expected.

Start by running the assessment script. Document your dependencies. Map XMLRPC methods to REST v2 endpoints. Build a migration plan with clear milestones and test checkpoints. Refactor your code incrementally, testing as you go. Participate in the brownouts to validate your progress.

If you’re managing multiple integrations, prioritize the most critical ones first. If you’re working with external developers or third-party tools, confirm their migration plans immediately. If you’re running custom code built years ago by someone who’s no longer available, allocate extra time for discovery and refactoring.

The brownout schedule is your friend. Use it. When XMLRPC goes offline during a scheduled test and your system breaks, you’ve just identified a dependency. Fix it, test again during the next brownout, and repeat until nothing breaks.

By the time the final brownout starts on December 8, 2026—23 days before the permanent shutdown—your integration should be running entirely on REST v2 with zero XMLRPC dependencies.

Get Expert Help

Migrating from XMLRPC to REST v2 isn’t trivial. It requires technical expertise, careful planning, thorough testing, and time—three things most businesses struggle to allocate in the middle of daily operations.

At 4Spot Marketing, we specialize in Keap integrations and automation. We’ve built, maintained, and migrated countless XMLRPC-based systems over the years. We understand the nuances of both APIs, the common pitfalls in migration projects, and how to minimize disruption to your operations.

We can assess your current integrations, document dependencies, map XMLRPC methods to REST v2 endpoints, refactor your code, implement proper error handling and token management, test thoroughly during the brownout schedule, and ensure your system is fully functional before the December 31, 2026 deadline.

If you need help making these changes, contact us today for a free quote.

We’ll review your specific situation, provide a clear migration plan, and give you confidence that your integrations will continue working long after XMLRPC disappears.

Frequently Asked Questions About Keap’s XMLRPC API Sunset

1. When does Keap’s XMLRPC API completely shut down?

Keap’s XMLRPC API will be permanently retired on December 31, 2026. After this date, all XMLRPC-based integrations will stop working completely with no fallback option.

2. What happens if I don’t migrate from XMLRPC to REST v2 by the deadline?

If you don’t migrate by December 31, 2026, your integrations will stop working entirely. Contact syncs will fail, campaign triggers won’t fire, tag applications will break, and any automation or data flow relying on XMLRPC will cease to function.

3. What are brownouts and how do they help with migration?

Brownouts are temporary, scheduled periods when XMLRPC services are unavailable. They help you discover which systems still rely on XMLRPC so you can complete your migration with confidence. Your data remains safe, and REST v2 services continue working normally during brownouts.

4. What is the brownout schedule for 2026?

The brownout schedule progressively increases in duration: March 10 (4 hours), April 9 (8 hours), May 11 (12 hours), June 17 (16 hours), July 9 (24 hours), August 14 (36 hours), September 18 (48 hours), October 30 (84 hours), December 8 (96 hours), and final shutdown December 31, 2026.

5. Can I opt out of the brownout testing?

Yes, you can opt out by contacting Keap’s API team if you need uninterrupted XMLRPC service during migration planning. However, Keap strongly recommends participating as brownouts are the safest way to validate your migration is complete.

6. How much advance notice will I get before each brownout?

You will always receive an in-app notification 48 hours before each brownout, regardless of what’s shown in the published schedule. Keap may adjust dates or times as needed.

7. Why is Keap retiring the XMLRPC API?

XMLRPC is legacy technology that predates modern web standards. It has limitations in standardization, error handling, and authentication. REST v2 offers enhanced security, improved performance, better scalability, and expanded functionality using modern standards like HTTP/JSON and OAuth 2.0.

8. What are the main differences between XMLRPC and REST v2?

XMLRPC uses XML over HTTP with method-based calls and legacy keys. REST v2 uses JSON over HTTP with resource-based endpoints and OAuth 2.0 authentication. REST v2 provides structured JSON errors with HTTP codes, optimized payloads, and OpenAPI documentation for easier integration.

9. Does REST v2 have feature parity with XMLRPC?

Yes, as of October 2025, Keap achieved 100% feature parity between XMLRPC and REST v2. Nearly all XMLRPC methods have been migrated to REST v2 endpoints, with documented alternatives for the small number of endpoints not being converted.

10. How do I find all XMLRPC calls in my codebase?

Keap provides a Python script in their migration guide that scans your project recursively, searches for XMLRPC patterns (like ‘data(‘, ‘DataService’, ‘xmlrpc’), ignores common dependency folders, and exports all matches to a CSV file for analysis.

11. Where can I find the mapping between XMLRPC methods and REST v2 endpoints?

Keap has published a comprehensive resource mapping guide that lists every commonly used XMLRPC method alongside its corresponding REST v2 endpoint, organized by domain (Affiliates, CRM, Data, E-commerce, etc.).

12. What if my XMLRPC method doesn’t have a REST v2 equivalent?

A small number of XMLRPC endpoints won’t be converted to REST v2. Keap has published a separate article detailing these endpoints along with recommended alternatives. If your method isn’t listed, contact Keap’s API Specialist through the Developer Forum.

13. How does authentication work in REST v2?

REST v2 uses OAuth 2.0 for authentication. Your application obtains an access token that must be included in the Authorization header of each request. Access tokens have a limited lifetime, so your integration must refresh tokens periodically to maintain access.

14. What HTTP methods does REST v2 use?

REST v2 uses standard HTTP verbs: GET (read data), POST (create data), PATCH (update data), and DELETE (remove data). These methods operate on resource-based endpoints rather than invoking named methods.

15. How are errors handled differently in REST v2?

REST v2 returns structured JSON error messages with specific HTTP status codes (400 for bad requests, 401 for unauthorized, 404 for not found, 429 for rate limits, 500 for server errors) instead of generic XMLRPC fault messages, making debugging much clearer.

16. Are there official SDKs available for REST v2?

Yes, Keap provides official SDKs for multiple programming languages, automatically generated from the OpenAPI Specification. These SDKs are maintained in the Keap SDK GitHub repository and simplify integration with the REST v2 API.

17. What should I test during the migration process?

Test that all required data is returned correctly, mandatory fields are populated, data formats comply with REST v2 requirements, and common error scenarios (invalid input, unauthorized requests, rate limits, server errors) are handled properly.

18. What are the best practices for REST v2 integrations?

Centralize authentication handling, handle errors gracefully with proper HTTP status code checks, validate inputs and outputs, implement consistent logging and monitoring, design for scalability, document your integration thoroughly, and participate in scheduled brownouts.

19. Will my data be affected during brownouts?

No, your data remains completely safe during brownouts. Brownouts only affect XMLRPC service availability temporarily. REST v2 services continue to work normally, and no data is lost or modified during these scheduled outages.

20. How long should I expect the migration to take?

Migration timeline varies based on integration complexity. Simple integrations might take a few days, while complex systems with multiple dependencies could take weeks or months. Start early—migration projects always take longer than expected.

21. Where can I get help with my migration?

For technical questions, contact Keap’s API Specialist, Omar Almonte, through the Keap Developer Forum. For comprehensive migration assistance, professional automation consultants like 4Spot Marketing can assess, plan, and execute your complete migration.

22. What documentation is available for REST v2?

Keap provides comprehensive REST v2 API documentation, OAuth 2.0 guides, XMLRPC to REST v2 mapping guides, migration guides with step-by-step instructions, brownout schedules, and information about endpoints not being converted.

23. Do I need to change how I handle rate limiting?

Yes, REST v2 handles rate limiting differently than XMLRPC. When you hit rate limits, you’ll receive a 429 HTTP status code. You should implement retry logic with exponential backoff to handle these situations gracefully.

24. Can I run XMLRPC and REST v2 simultaneously during migration?

Yes, you can run both APIs simultaneously during your migration period. This allows you to migrate incrementally, testing REST v2 endpoints while maintaining XMLRPC functionality until you’ve completed and validated the full migration.

25. What happens on December 31, 2026?

On December 31, 2026, the XMLRPC API will be permanently shut down with no grace period, fallback option, or emergency access. Any integrations still using XMLRPC will immediately stop working and must be migrated to REST v2 beforehand.