Has legacy API keys been shut off for the XML RPC API? If so, why was this not communicated to users directly, with time to prep?
All of our API calls are getting back 403 Forbidden as of this morning.
I see in the API settings that there is a place to whitelist IPs, is this a required featured? If so, how do I use it, as there’s no way to save that setting.
(Just to head off any questions, we’re still using XML RPC as the V1 and V2 REST APIs still are not feature complete, and do not allow us to modify all the data structures we need to, in particular updating subscriptions, creating, and updating existing products, and a few others).
It looks like the forbidden responses stopped a few minutes ago.
Still, would appreciate an official response to the event, and what happened. Between this and several weeks ago a change to the API about how it handled dates on the query endpoint that was not communicated is worrying. I would love to switch to a newer stack, but the REST apis still aren’t feature complete years after being released.
There have been no changes to the Legacy XML-RPC API key authentication. It is possible that there was a transitory outage or deployment in the block of tenant applications you were attempting to contact, resulting in the error code response.
If the problem persists please file a complete support ticket with our Advanced Support representatives, as they have visibility to production concerns that we as engineering teams are not permitted for security reasons.
I was seeing of ton of the 403 errors from 11:37 to 11:52 AM central time. The errors are now back beginning 12:54 PM central time and currently continuing.
Both the earlier case and the current situation appears to be on the PHP SDK - OAuth side of Keap API.
CORRECTION - the issue may not be specific to the OAuth side - may be on the legacy API Key side instead - checking further.
UPDATE - I have confirmed it is on both the legacy API Key and OAuth side of the XML RPC api.
OK - CORRECTION - my post is in error - what I’m seeing is error messages with an incorrect timestamp - not Keap’s issue - the problem does appear to have cleared at 11:58 AM central and is no longer being seen. Sorry for the false alarm.