Unable to access API, possibly blocked?

problem
1

Hi NewsBlur team,

I run Enzo Reader, which integrates with NewsBlur through your API. A customer reported that their NewsBlur feeds work normally in the browser, but no articles synchronize into our system. Our investigation found the same connection failure across multiple NewsBlur user connections in our production environment.

Connection details

  • Source server IP: 172.237.159.95

  • Destination: newsblur.com → 65.108.152.3, TCP port 443

  • API operation failing: POST https://newsblur.com/api/login

  • Verified: September 18, 2026, approximately 15:46 UTC

The application records:

NewsBlur login failed: Net::OpenTimeout:
Failed to open TCP connection to newsblur.com:443 (execution expired)

The connection fails before authentication or an HTTP response.

Could you check whether 172.237.159.95 is blocked or filtered on your side, or whether there is a routing issue affecting this source address? We can run additional diagnostics if helpful.

Could our shared production IP have triggered an automated abuse or login-rate block? All 20 connected accounts use this address. If so, please share the triggering request pattern and recommended limits so we can correct it before access is restored (and if we did do something that got us blocked, we’re very sorry!)

2

Yes, that IP is blocked at our firewall, and has been since July 9th. So this isn’t a routing problem, and it isn’t new. I no longer have the logs from when it was added, so before I lift it I’d like to understand what the integration does so it doesn’t end up blocked again. Can you share which endpoints you call, how often each account syncs, and what the client does when a request fails or times out? Twenty accounts behind one IP is fine, but the combined rate should stay under roughly 100 requests a minute and failures need to back off instead of retrying right away. Once I have that I’ll remove the block.

3

Thanks for the reply! Interesting regarding the timing. Yes, will provide all of that but let me first verify that the total rate limits are being respected first. I’ll be back with that confirmation and all requested details…

4

Ok, I think I see what happened. The date was the key - a test container was incorrectly deployed to production in early July and it’s very possible (likely, tbh) that it totally ignored rate limits, especially on retries.

I’ve also gone an re-validated the rate limiting configuration based on the above and verified it is under ~75 requests/min. For retries, the first one is at 60 seconds, then 60 minutes and then it’s discarded. We also respect the ‘Retry-After’ header if present. Will that be acceptable?

Enzo Reader is a RSS reader plugin for ChatGPT (i.e. read your feed items in ChatGPT, provide them as context, etc). We call the following endpoints at various times:

Method Endpoint Purpose
POST /api/login Authenticate and obtain a session cookie
GET /reader/feeds Fetch subscriptions and feed metadata
GET /reader/unread_story_hashes Fetch unread article identifiers
GET /reader/river_stories Fetch articles: unread batches or paginated history
GET /reader/starred_stories Fetch saved articles, with pagination
POST /reader/mark_story_hashes_as_read Mark articles read in a batch
POST /reader/mark_story_hash_as_unread Mark an article unread
POST /reader/mark_story_hash_as_starred Save an article
POST /reader/mark_story_hash_as_unstarred Unsave an article