Walled Gardens: The API Clauses Slack, Reddit, SAP and Atlassian Wrote for AI

Since 29 May 2025, the Slack API terms have barred any app offered outside its builder's organisation from using API data to train a large language model. The same update cut unlisted commercial apps to 1 history request a minute. Those clauses read as a SaaS walled garden, and they are. They also leave a door open for agents you build on your own data, which almost nobody is reading closely.

The short answer. Slack, SAP and Atlassian have each restricted how outside AI systems reach customer data through their APIs, in clauses dated between May 2025 and April 2026. If you build an agent on your own SaaS data, you are mostly allowed through. If you buy one from a third party, check which pathway it uses and what the terms say about it.

SaaS walled gardens are written in the terms, not the rate limit

A walled garden is a platform that controls who can reach the data inside it, and on what conditions. In consumer tech the term describes app stores. In B2B SaaS it now describes your own company's conversations, tickets and records.

Most coverage of this shift has focused on throttling. Rate limits are visible, measurable and easy to complain about. The cost of those limits as a hidden toll on agents is set out in the comparison of how SaaS vendors meter MCP and API access, and this post does not repeat that work.

This post reads the contract text instead. A rate limit can be raised next quarter with one support ticket. A clause in the API terms of service is a rule about what you may do with the data at all. It survives every infrastructure upgrade, and it is what a vendor will point to in a dispute.

I think the clauses matter more than the limits, for one reason. A limit tells you how fast you may go. A clause tells you whether you may go there at all, and who decides.

This post is written for an ops or delivery lead who owns an agent roadmap. You have a plan to point agents at Slack, Jira, Confluence or an ERP. You need to know which of those plans the vendor's own paperwork already forbids.

The ledger: 13 dated API terms changes aimed at AI

Every row below is dated and traced to the document that made the change. Where the primary text could not be opened, it is traced to reporting. Where a clause is quoted, the wording is the vendor's own.

Dates are the effective or filing date where one exists, otherwise the publication date. The Reddit price row rests on press reporting of the rate. The SAP row rests on secondary reporting of the clause, for the reason given in the SAP section below.

Slack API terms on AI: three prohibitions and one exemption

Salesforce changed the Slack API terms on 29 May 2025. The Slack developer changelog states the terms applied immediately to apps created on or after that date, and from 30 June 2025 to older apps. The version live as I write carries the line "Effective: 10th October 2025".

The operative clause sits under a heading on data usage by third parties. It reads, in full: "As the provider of an Application offered for use outside your organisation, you may not: (A) use API Data to train a large language model; (B) bulk export Slack message and file data except where expressly allowed by an additional agreement, such as by Applications using the Discovery API for approved security and compliance use cases; or (C) use data collected from one organisation to directly benefit a different organisation or any third party."

Clause A: no LLM training on API data

The wording names large language models specifically. It does not say "AI" or "machine learning". A narrow reading would allow a classifier or an embedding index trained on Slack data. I would not build a business on that reading, because the same terms also require you to limit retention to "the minimum necessary" to operate the app.

Clause B: no bulk export

This is the clause that hit enterprise search vendors hardest. Glean told its customers the change hampered "your ability to use your data with your chosen enterprise AI platform", as quoted by law firm Hunton in July 2025. Glean said access would now run "on a query-by-query basis". The permissions side of that dispute is examined in the comparison of how Glean and Copilot inherit source permissions.

Slack's stated reason is specific. The changelog says bulk downloads of conversational data "pose risks of exposing sensitive information and undermining Slack access controls, such as private channel membership". That is a real risk, and I return to it in the limitations section.

Clause C: no cross-customer benefit

Clause C is the least discussed and arguably the most important for vendors. It stops an app provider from pooling what it learns from your workspace into a product sold to someone else. In plain terms, no vendor may build a shared model or benchmark out of its customers' Slack data.

The exemption almost nobody reads

The opening phrase decides the scope: "an Application offered for use outside your organisation". An internal app your own team builds for your own workspace is not offered outside your organisation. The changelog confirms the operational side: "Internal customer-built applications are not impacted by these changes."

The gap in throughput is large. Internal apps keep 50+ requests a minute on the history methods, with a limit parameter of up to 1,000 objects. A new unlisted commercial app gets 1 request a minute at 15 objects.

The calculation behind that caption: 15 messages a minute is 21,600 a day. An internal app at the stated floor reads 50,000 a minute. Slack did not wall off your data from you. It walled off your data from vendors it has not approved.

The door Slack opened for approved partners

Slack's replacement path is the Real-Time Search API, which answers queries without the app storing the data. On 17 February 2026 Slack made it generally available alongside an MCP server, saying more than 50 partners, including Anthropic, Google, OpenAI and Perplexity, were building on it. On 23 June 2026 Anthropic launched Claude Tag, a shared @Claude that joins Slack channels as a team member, in beta for Enterprise and Team customers.

The pattern is consistent. Bulk access closed, query access opened, and the gatekeeper chooses who is on the list.

Reddit: the walled garden enforced in court

Reddit is a different case from the other three, and it belongs in this ledger for that reason. Its data is public posts, not a customer's private records. It shows what a platform does once it decides its data is a licensable asset.

The sequence ran from price to filing to lawsuit. In June 2023 Reddit's commercial API rate was reported at $0.24 per 1,000 calls, which the developer of the Apollo app estimated would cost over $20 million a year. Apollo shut down on 30 June 2023.

By its 2024 annual report, filed on 13 February 2025, Reddit described the threat in plain terms. Third parties "often attempt to access and collect Reddit site data through 'scraping' and other unauthorized mechanisms for unauthorized purposes, such as distributing such data to other parties for commercial purposes or training AI models for commercial purposes."

Two lawsuits in five months

On 4 June 2025 Reddit sued Anthropic in San Francisco Superior Court, case CGC-25-524892. The claims include breach of contract, resting on a user agreement that requires a licence for commercial use, plus unjust enrichment and unfair competition. Anthropic said it disagreed and would defend itself.

On 22 October 2025 Reddit sued Perplexity, SerpApi, Oxylabs and AWMProxy in the Southern District of New York. Reddit alleged the defendants scraped its content from Google search results to get around its own blocks. Perplexity said it would fight for users' right to access public knowledge. I found no ruling in either case as of this writing.

The deal values behind Reddit's licensing are tallied in the ledger of AI content licensing deals. The lesson for a SaaS buyer is not the price. It is that a platform which can price access will also litigate unpriced access, and your SaaS vendors have now watched that play out.

SAP's API policy names agentic AI in the clause itself

Slack's clause targets training and export. SAP's targets the agent pattern directly. In late April 2026 SAP published API Policy v4/2026, and Techzine reported in May 2026 that section 2.2.2 restricts AI systems that independently schedule or execute calls.

The fuller wording, as reproduced by the analyst blog aheadCRM on 29 April 2026, reads: "Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for interaction or integration with semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls."

What "endorsed pathways" means in practice

The clause does not ban AI. It bans the agent you choose, reaching SAP by a route SAP did not choose. Commentators list Joule, Business Data Cloud and SAP's integration gateways as the sanctioned routes. Techzine reported SAP's chief customer officer saying agent-to-agent traffic through Joule is the only way for agentic use cases.

This is the clause I would negotiate before an SAP renewal. Unlike Slack's, it is not limited to apps offered outside your organisation. Read literally, it reaches an agent your own team builds and points at your own ERP. What SAP and Oracle have actually shipped on the agent side is covered in the inventory of ERP AI agents customers switched on.

Atlassian prices the work instead of banning the use

Atlassian took the quieter route. Its Developer Terms, last updated 1 December 2025, allow it to set limits "on points that reflect the work performed in response to an API request". In the portion of those terms I could read verbatim, I found no clause on training AI models with API data.

On 12 December 2025 Atlassian's head of ecosystem product announced points-based quotas, with phased enforcement from 2 March 2026. The Atlassian platform blog gave a direct steer: an app that "supports AI-based features" and misses the higher tier should "consider using Atlassian Rovo MCP as an alternative to direct API queries".

The API token carve-out

The new quotas cover Forge, Connect and OAuth 2.0 apps. Atlassian's documentation states that "API token-based traffic is not affected by this change". A script your own admin runs with an API token sits outside the points system, for now. Atlassian says it is evaluating token usage patterns, so treat that as a current state, not a promise.

Who the clauses actually bind: your agent or your vendor's

Read together, the four vendors draw the same line in different places. The line runs between agents you build on your own data and agents a third party sells you. The second group carries almost all of the restriction.

This is a reading of published terms and documentation, not legal advice. Your enterprise agreement may override the developer terms in either direction, and that is the first document to check.

The strategic consequence for your roadmap

Here is my position, stated plainly. The cheapest way around a SaaS walled garden is to stop being a third party. For your first agents on Slack or Jira data, an internal build is no longer only a cost decision. It is the route the terms favour. The wider trade-off is weighed in the analysis of when building beats buying.

The second consequence is lock-in. Each approved route runs through the vendor's own agent layer or its chosen partners. If your agents can only reach your data through Joule, Rovo or a Marketplace listing, the vendor has become your AI platform by default. I think that is the actual commercial point of most of these changes, whatever the stated rationale.

Where this argument is weakest

Four points cut against the reading above, and each one is serious.

The privacy rationale is genuine. A third-party index of every Slack message can leak private channel content to people who were never members. Slack named that exact risk. A vendor restricting bulk copies of conversational data is doing something a careful security team would also ask for. Calling it only a land grab ignores that.

The wall has gates. Slack says more than 50 partners build on its query API, including direct rivals of Salesforce's own AI. That is not a closed garden. It is a toll road with a guest list, which is a weaker charge than exclusion.

The SAP wording is secondhand. I opened SAP's own policy PDF during research but could not extract its text. The clause quoted here comes from an analyst blog, corroborated in substance by Techzine. Read section 2.2.2 in the original before you act on it, and check SAP's FAQ on customer-run MCP servers, which commentators say permits them without support.

Terms move faster than posts. Slack's live terms already carry an October 2025 effective date, newer than the May 2025 change. Any row in this ledger can be superseded without announcement. Your enterprise agreement may also override the developer terms, which is why the contract is the place to fix this, not the developer portal. The clause language to ask for is covered in the list of AI contract clauses a CFO should insist on.

Frequently asked questions

Where to start

Pull the list of every AI tool that touches Slack, Jira, Confluence or your ERP. For each, write down one fact: is it an internal build, a vendor-approved route, or a third party on its own route? Anything in the third group is where your next outage or contract dispute will come from.

Then take that list to your next SaaS renewal and ask for one sentence in the order form. It should confirm your right to access your own data through the API, by agents you build or appoint, at stated limits. A vendor that refuses to write it down has told you which way the wall faces.

Related reading