TLDR: Slack's new rate-limit regime for non-Marketplace apps can be brutal — but whether your app is on it isn't in the docs. You have to probe live.

The thing I was trying to build

I've been building what I call the Apollo dashboard — my personal AI-powered daily briefing that surfaces email, Slack, and calendar context all in one place, cached locally so the AI has real depth to work with.

One feature I wanted badly: 90-day Slack history, pulled once and stored, so when I'm reading a thread I have real context on everything that came before it.

That's when I hit the question that stopped me cold.

The wall (on paper)

I use Arcade (my MCP auth provider, which handles OAuth to Gmail, Slack, Google Calendar so Claude can actually act on my behalf) to connect to Slack across three workspaces — an ecommerce business and two other workspaces.

And I'd just read that Slack moved non-Marketplace apps created after ~May 2025 to a punishing new regime.

We're talking conversations.history capped at roughly 1 request per minute, max 15 objects per request.

Old Tier-3 was ~50 requests per minute with hundreds of objects. This new cap is brutal by comparison.

For a 90-day scrollback cache, that math is… not good.

The thing that makes this tricky

Here's what got me: you cannot tell from the docs which regime you're on.

It depends entirely on when the underlying app was created — not your account, not your plan. The app's creation date.

So the Arcade Slack app could be on the generous old regime or the brutal new one, and Slack's rate-limit documentation just… doesn't tell you.

The only way to know is to probe it live.

What I actually did

I wrote a quick read-only test — raw GET conversations.history call on a an ecommerce business DM, asking for limit=200.

Got back 19 messages in a single call. If the 15-object cap were in effect, I'd have gotten at most 15.

Then I fired off 3 rapid-fire repeats. All three came back 200. No Retry-After header. No throttling signal at all.

Then I checked a DM in one of the other workspaces — it returned a next_cursor, which means cursor pagination for deep backfill actually works.

The Arcade token is on the generous tier. 90-day scrollback: feasible.

The separate (and annoying) Gmail story

While I was in there auditing limits, I found that the Gmail side of Arcade has its own class of gotcha — not rate limits, but tool quirks.

Filtering by category:primary returns nothing. Noise floods from newsletters and automated messages eat the entire max_results window before anything meaningful surfaces. It requires a different strategy entirely.

That's a topic for another post. But the lesson is similar.

Why this matters

If you're building anything that does deep or eager API pulls — Slack history caches, email digests, anything that calls in a loop — you cannot trust the docs to tell you which regime you're on.

Probe live. Look for Retry-After headers. Check how many results actually come back against your limit. See if next_cursor works.

The probe cost me maybe 20 minutes.

Not knowing could have sent me down a completely wrong architectural path — designing around a constraint that didn't actually apply to my token.

Always verify the regime before you design around it.