An AI company wants API access to your platform instead of a file

Should you give API access instead of a file?#

Giving an AI company API access instead of a file is rarely the right first step; most companies should start with approved file snapshots and consider a feed only after the first releases have proved the preparation process. Buyers ask for feeds because they want recency and less manual handling, and both are fair goals.

The risk is structural. With a file, a person reviews exactly what leaves. With a feed, a set of rules decides every time, without anyone watching. Any change at the source, such as a new ticket field, a new Slack channel or a new customer segment, flows through unless the rules anticipated it.

File snapshot versus live feed#

File snapshots and live feeds differ on almost every dimension a supplier cares about. The comparison assumes the records are your own, such as support history or engineering records, and that they have already passed rights review.

Why revocability is weaker than it looks#

Revocability in a feed is weaker than it looks because revoking a key only stops what has not yet been pulled. Data already retrieved sits in the buyer's storage, and anything used for training is reflected in model weights that cannot simply be rolled back.

The protection that matters in both models is therefore contractual: permitted use, retention limits, deletion certification for raw data and clear terms for derived artifacts such as embeddings, indexes and trained models. A feed does not remove the need for those terms. It only changes how quickly data accumulates on the other side.

Questions to ask the buyer before deciding#

The buyer's answers to a few direct questions usually show whether a feed is needed or merely convenient. Ask them in writing, early, and keep the answers with the deal file, because they also shape permitted use and retention terms.

If the answers point to evaluation on a fixed historical set, a snapshot is the natural fit. If they point to an ongoing product need, the conversation moves to scheduled refreshes or a staged feed.

• 1What will the records be used for: training, evaluation, or both?
• 2How fresh do records need to be, and what breaks if they are older?
• 3Which objects and fields does your pipeline actually consume?
• 4Will raw records be stored, and for how long, after they are processed?
• 5Who on your side holds credentials, and how is access logged?
• 6What format and delivery channel does your team already support for files?

Keeping approval per release if you build a feed#

Approval per release can survive in a feed if the feed is built as a series of small releases rather than a pipe into source systems. The design principle is to put a prepared, reviewed copy between production and the buyer.

This design costs more to build than a one-off export, and it should, because it carries a continuing obligation. Budget the maintenance and name the owner before agreeing to it.

• 1Serve the feed from a staging store filled by your preparation pipeline, never from Zendesk, GitHub or a production database directly.
• 2Use a schema allowlist so new fields and objects stay blocked until someone reviews them.
• 3Group records into releases with a manifest, and require a named approver before each batch is exposed.
• 4Cap volume per release and alert on unusual pull patterns.
• 5Log every request and review the logs on a set schedule.
• 6Keep a documented kill switch with an owner and a backup owner.

The middle path: scheduled, approved refreshes#

Scheduled, approved refreshes give buyers most of the recency they want without live access. The supplier prepares a new snapshot on an agreed cadence, reviews it, approves it and delivers it through the same channel as the first release.

Most buyer needs can be met this way, and the table shows where a feed becomes worth discussing. Delta files, which contain only records added or changed since the last release, keep refreshes small and easy to review.

Illustrative: a roofing estimating software company says not yet#

Illustrative: a fictional software company that sells estimating tools to commercial roofing contractors agrees in principle to license its support conversations and linked Jira issues. The buyer asks for read access to the Zendesk and Jira APIs so it can pull new records as they appear.

The CTO points out that both systems hold customer attachments and internal comments that preparation would have to handle on every record, and that a Zendesk custom field added last year would have flowed straight through unreviewed. The company offers a historical snapshot first, then refreshes on an agreed cadence, each prepared from a staging copy and approved by the head of support and general counsel.

After several releases pass without issues, the parties revisit the feed question with a schema allowlist and batch approvals in place. Until then, every record the buyer holds is one a named person approved.

How SourceX handles delivery format#

SourceX handles delivery format in the Delivery step of the SourceX five-step transaction, after Supply, Rights, Preparation and Approval are complete. Large datasets stay in the seller's own storage or ship on encrypted drives, and SourceX does not host multi-terabyte datasets.

Each release carries a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization. Because authorization is recorded per release, the packet fits snapshots and scheduled refreshes naturally; any continuous arrangement would need the same authorization recorded for every batch.