Rights and contracts
App marketplace partner terms: can ISVs reuse data accessed via a platform?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
An ISV usually cannot license data it pulled through a platform's API until three layers clear: the platform's developer and partner terms, its own contract with each shared customer, and that customer's agreement with the platform. Several platforms now restrict AI training on API data outright. Build the license around records the ISV created itself.
Key takeaways
- Data obtained through a platform API is usually governed by the platform's terms, the ISV's customer contract and the customer's own platform agreement at once.
- Records an ISV creates in its own systems, such as Jira issues, GitHub reviews and Zendesk tickets, are the natural core of a license.
- Synced objects, cached API responses and webhook payloads should be treated as excluded until counsel confirms otherwise.
- Slack and HubSpot developer terms now restrict using API data to train AI models, so read the live text and keep dated copies of each version.
- Integration data leaks into logs, error payloads and pasted ticket text, so filtering has to reach beyond the sync tables.
Can an ISV license data it pulled through a platform API?#
An ISV can rarely license platform API data on its own say-so, because that data usually sits under three overlapping agreements. The platform's developer terms and marketplace partner agreement set what listed apps may do with data they access. The ISV's subscription agreement or DPA with the shared customer sets what the ISV may do with that customer's records, and the customer's own agreement with the platform can add limits of its own.
Most of those documents tie API access to a narrow purpose: providing the app's features to the customer who installed it and granted the OAuth scopes. Licensing that data so another company can train a model sits outside that purpose unless a clause says otherwise, and several large platforms now say so in writing.
The practical answer for a CTO is to separate what the company created from what it received through an integration, and to treat the second group as excluded until counsel has read the clauses below.
What do recent platform terms say about AI training?#
Recent platform terms increasingly name AI training on API data as a prohibited or restricted use, which removes much of the guesswork for an ISV. The examples below come from the platforms' own published terms and changelogs or, where noted, from press reporting.
Terms like these govern apps that read other organizations' data. They are separate from the customer terms that govern a company exporting its own workspace, and they change: Slack's developer changelog said its 2025 clarifications took effect immediately for new apps and on June 30, 2025 for existing apps. Read the live text, and keep a dated copy of each version you rely on.
| Platform | What the terms or reporting say | What it means for an ISV license |
|---|---|---|
| Slack | API Terms say an app offered outside the provider's own organization may not use API Data to train a large language model or bulk export message and file data unless an additional agreement expressly allows it | Slack messages your app synced stay out of a training license |
| HubSpot | Developer changelog says updated Developer Terms restrict using API data to train, fine-tune or improve AI or machine learning models, with a carve-out for legitimate single-customer use cases, and that customer data belongs to the customer | Synced HubSpot records are excluded; a feature serving one customer is a separate question |
| Procore | ENR reported in November 2025 that its terms bar marketplace partners from bulk-downloading platform data for commercial purposes, including training large language models | Project records mirrored from Procore stay out |
| Zendesk | Developer Terms bar repackaging or reselling the services, APIs or API Data | Relicensing ticket data pulled through the API is hard to square with that bar |
| ServiceTitan | API Terms license the APIs only to develop, test, use and maintain an interconnection between your application and the platform | Job data synced through the API serves the integration, not a license |
Which ISV records are usually yours to license?#
Records your own team generated in your own systems are usually the strongest and cleanest part of an ISV license. The difficulty is that many apps store both kinds of data side by side, often in the same database and the same warehouse.
The table gives a default position for each record family. A default is a starting point for review, not a conclusion, and the customer contract question still applies to anything that mentions a customer.
| Record type | Typical system | Default position |
|---|---|---|
| Issues, sprints and product decisions | Jira, Linear, Confluence | Usually licensable after review |
| Code, pull requests and code reviews | GitHub, GitLab | Usually licensable; check open source and customer code |
| Support tickets about your app | Zendesk, Intercom | Licensable after de-identification; strip pasted platform records |
| App telemetry and error logs | Analytics and logging stack | Review first; payloads may carry platform data |
| Synced platform objects | App database or warehouse | Exclude unless every governing term allows it |
| Cached API responses and webhook payloads | Queues, caches, object storage | Exclude |
| Install and billing data from the marketplace | Partner portal exports | Check partner terms; often restricted |
Partner agreement clauses to review before scoping a license#
The partner agreement clauses that matter most are the ones that define platform data and limit its purpose. Read the marketplace partner agreement, the API or developer terms it incorporates, the security review requirements and the listing policy together, because restrictions are often split across several documents.
Keep a dated copy of every version you rely on. Platform terms are amended regularly, and the version in force when the data was collected can differ from today's in ways that matter for historical records.
| Clause | What to look for | Why it matters |
|---|---|---|
| Definitions | How platform data, customer data and end-user data are defined | Decides which of your tables the restrictions reach |
| Permitted purpose | Use limited to operating the app for the authorizing customer | Licensing to a third party usually falls outside it |
| AI and machine learning use | Express bans or conditions on training models with API data | Answers the question directly when present |
| Storage and caching | Limits on how long data may be kept or copied | Old synced data may already be out of bounds |
| Aggregate or derived data | Carve-outs for de-identified or aggregated data | Sometimes the only route for platform-derived signals |
| Deletion on uninstall | Duties to delete when a customer removes the app | Historical copies may need purging, not licensing |
| Survival and amendments | Which terms survive exit and how updates take effect | Data can stay bound after you leave the program |
How your customer contracts add a second layer#
Your customer contracts add a second layer because the shared customer is also your customer. If your subscription agreement makes you a processor or service provider under a DPA, you generally may process that customer's personal data only on its instructions, which generally rules out licensing it for a buyer's model training.
Look for an aggregated or anonymized data clause in your MSA. Where one exists, it may let you use de-identified usage patterns from your own service, but it rarely reaches data that belongs to the platform relationship. Enterprise addenda and security exhibits can narrow it further, so read the paper for your largest accounts separately rather than relying on the standard template.
Where integration data hides in an ISV's systems#
Integration data hides well beyond the sync tables, which is why exclusion has to work by field and payload, not only by table. Engineers paste records into tickets to reproduce bugs, and error trackers capture full request and response bodies by default.
A useful first pass is to search tickets, issues, chat and logs for the platform's record ID formats and object names. Each hit is then redacted in place or the item is dropped, and the rule used is written down.
- Application tables that mirror platform objects such as contacts, deals, orders or tickets.
- Warehouse copies and analytics events that carry platform record IDs or field values.
- Error tracking and log payloads that store API requests and responses.
- Support tickets and Slack threads where staff pasted customer records to debug a sync.
- Test fixtures and seed data copied from production accounts.
- Jira issues with attached CSV exports or screenshots of a customer's platform view.
Illustrative: a scheduling app on a CRM marketplace#
Illustrative: a fictional field service scheduling vendor has sold its app through a CRM marketplace for most of a decade. Its Jira projects, GitHub repositories and Zendesk queue hold years of linked issues, fixes and support outcomes. Its Postgres database also mirrors accounts, contacts and work orders from every customer's CRM instance.
The CTO maps each source against the partner agreement and the company's MSA. The partner terms limit API data to operating the app, and the MSA names the vendor as a processor. The team excludes all synced objects, the warehouse tables that join to them and the error tracker payloads, and it redacts CRM record snippets found in tickets.
The resulting package is narrower but clean: code reviews, issue histories and support conversations about the vendor's own product. Counsel signs off on the scope, and the rights review records which sources were excluded and why.
How SourceX handles platform-sourced data#
SourceX handles platform-sourced data as a Rights question within the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. During the fit check, an ISV describes its systems and integrations as metadata only, and no files or API data change hands.
Where a package proceeds, the SourceX Evidence Packet records provenance by source system, the licensing rights relied on and the platform data excluded, permitted use, the privacy record and the supplier's release authorization. The supplier approves the final scope before anything is delivered.
Frequently asked questions
Does a deletion duty on uninstall affect records we still hold?
It can. If the partner terms required deletion when a customer uninstalled your app, copies of that customer's synced data that still exist may already be out of compliance. Those copies belong in a deletion review, not a license. Your own tickets and code about that customer's issues are a separate question for your customer contract.
Are metrics about API calls, such as error rates or latency, licensable?
Operational metrics about your own service, such as error rates, retry patterns and latency, are usually your records rather than platform data. Confirm that the metrics do not embed field values or record identifiers, and check the partner terms for any clause covering derived or aggregate data before including them.
Can we ask the platform for permission?
You can, and some terms anticipate it: Slack's API Terms allow bulk export of message and file data only where an additional agreement expressly permits it. A written consent or amendment settles the platform layer, but it does not replace your customer contracts or privacy obligations, so treat it as one approval among several.
Which version of the platform terms applies to data collected years ago?
That depends on how the terms handle amendments and survival, which differs by platform. Keep dated copies of past versions where you can, compare them with the current terms, and let counsel decide which version governs each slice of historical data.
How should we describe platform data to a prospective buyer?
Say plainly that platform-sourced data is excluded unless and until rights are confirmed. Buyers ask about provenance, and a precise account of what was removed and why builds more confidence than a broad claim that everything is covered.
Sources
- Slack's API Terms of Service state that a provider of an application offered for use outside its own organization may not use API Data to train a large language model, and may not bulk export Slack message and file data except where an additional agreement expressly allows it. Source
- Slack's developer changelog announced API Terms of Service clarifications that took effect immediately for new apps and on June 30, 2025 for existing apps. Source
- HubSpot's developer changelog says its updated Developer Terms restrict using data accessed through HubSpot APIs to train, fine-tune or improve AI or machine learning models, with a carve-out for legitimate single-customer use cases, and state that customer data belongs to the customer, not to HubSpot or developers. Source
- ENR reported in November 2025 that Procore's terms of service now say marketplace partners cannot bulk-download data from its platform for commercial purposes, including training large language models. Source
- The Zendesk Developer Terms bar repackaging or reselling the Services, APIs or API Data. Source
- ServiceTitan's API Terms grant a limited, non-exclusive, nonsublicenseable, nontransferable license to use the APIs only to develop, test, use and maintain an interconnection between your application and the platform. Source
Related resources
- QuestionDo AI labs buy legal documents?
- InsightCan a 3PL license warehouse video to robotics and AI developers?
- InsightMCP and your business data: is connecting AI tools the same as licensing?
- InsightCan a buyer release open-weight models trained on your data?
- SolutionHow AI developers source data
- IndustryBPO & contact centers data
See if your company qualifies
A short company assessment. No data uploads are needed.