Sudden 404 error on REST API v2 requests (previously working for years)

Hi,

we have an issue with our integration that has been stable for years.
Our system connects to Keap via REST API v2, and everything has been functioning normally until today.

Without any code changes on our side, all requests to the standard REST v1 endpoints suddenly started returning 404 Page Not Found.
This includes endpoints that were previously working (contacts, tags, custom fields, etc.).

This looks like something may have changed on Keap’s side, since we’re receiving a generic Keap “Page Not Found” HTML page rather than a structured API error.

Could you please check whether there are any known issues with REST v1 endpoints or any deprecations/changes rolled out today?
If needed, we can provide request samples, timestamps, and headers.

Thanks in advance for your assistance.

Hi @Dijana_Domonkos,

Thanks for reaching out. We haven’t made any recent changes that would affect the paths of our APIs, and everything seems to be working fine on my end. Could you please share the specific details of the requests you are making?

Hi Omar, it’s an integration with our software that has been working for years now without any issues.

But today it said the token has expired. I generated a new API key, but received same message:

p { font-size: 14px; color: #666666; width: 500px; text-align: left; margin-bottom: 14px; }

a {
font-size: 14px;
}

Keap - Page Not Found
You must enable Javascript to use Keap!
Page Not Found

We're sorry to say this, but the page you're looking for can't be found. This usually happens if you click on a broken or incorrectly-formatted link, or enter the wrong web address.

If you're the owner of this account, click here to login.

Hope this helps, let me know if you need more details!

Dijana





|

Dijana Domonkoš



CEO



Crew Media d.o.o.








M: +385 99 435 4397



E: info@crewmediagroup.com



www.crewmediagroup.com

|

  • | - |

Can you share an example of a specific request your integration is making, including the full URI it’s trying to hit?

Hi, thanks for your reply.
Here is an example of a call that returns the 404 Page Not Found HTML response.
Request:
Method: GET
URL:
https://api.infusionsoft.com/crm/rest/v1/contacts/?given_name=John
Headers:
Authorization: Bearer token
Content-Type: application/json
Body:
(empty – standard GET request)
This exact request has been working for years without any changes on our side.
It also works normally when using a different token for our other Keap apps (Orto Nova and White City Dent), so the request structure is valid — only this specific app/token returns the 404 HTML page.

Thanks!

Thanks for sharing the full request, the issue is caused by the extra trailing slash after contacts.
You’re calling:

/crm/rest/v1/contacts/?given_name=John

but the correct path should be:

/crm/rest/v1/contacts?given_name=John

I tested the corrected endpoint using the token you provided, and it worked normally.

Note: please don’t share your access token publicly. Anyone with that token could access the API and authenticate as if they were you, it should be treated as very sensitive information. I’ve edited your post to remove it.

Hi Omar,

I am replying by e-mail, so wasn’t aware this was going publicly, thank you for the heads up :slightly_smiling_face:

But thank you very much, you are totally correct, it works now!

Thank you for your fast and excellent help!

1 Like

@OmarAlmonte thanks for the help, I experienced the same issue, and after removing the “/” before the “?” is started working again.
One issue I still see is when Im iterating over /contacts Im getting a URL in the next property and this URL have the redundant slash before the “?”.
I added code to remove it, but If Keap is no longer support having this slash before “?” then the next URL should be fix as well.
Thanks

1 Like

You’re very welcome @Dijana_Domonkos and @Amir_Aburus! We noticed that requests to REST v1 endpoints with a trailing slash (/) used to work, but after a recent update, they temporarily stopped being supported. This has now been fixed, so the old behavior should work again.