About
Programmatic access to your deal flow: fetch and search deals, spot deals going cold, and create, update, move, or archive deals from your own code. Pipeline structure (creating pipelines, editing stages) and pipeline analytics have their own page — see the Pipelines API. All operations go through the developer API gateway — one endpoint, called byoperationId. If you haven’t set up a key yet, start with the
Developer API Overview.
Operations
Reading deals (READ scope)
findDeals and listStalledDeals are paginatedBoth return up to 50 rows per call (a larger
limit is clamped) but take an
offset and return totalCount + hasMore, so you can page through the full
set: send offset: 0, then offset: 50, and so on until hasMore is false. See
Result limits & truncation.Writing deals (WRITE scope)
Deal money fieldsCommission and team split each accept one source: a fixed
*AmountCents or a
*PercentBps, never both. commissionCents is the server-derived GCI to
report. Participant splits allocate what remains after the team fee. For deal
custom fields, use the value member that matches the definition type; DOLLAR
values are plain numbers, not cents, and dropdown values are option labels.Guarding against a concurrent editPass
expectedUpdatedAt — the updatedAt you got from getDeal, findDeals,
or a previous write — to make the update conditional. The write applies only if
the deal hasn’t changed since; otherwise nothing is written and you get
CONFLICT. Use it whenever you decided what to write from a copy you read
earlier, so a concurrent edit fails loudly instead of being silently
overwritten.Organization guardDeal operations are org-guarded: the deal (and any destination stage) must
belong to a pipeline owned by or shared with your organization, or the call
returns
403 forbidden. Pipelines shared with your org through a
partnership work normally. See
Authorization for the full
owned-vs-shared model.