Skip to main content

GET /sdk/v1/campaigns/:campaignId/contracts/sync

Sync contract history across an entire campaign without requesting each creator separately. Each version is a separate record, so large histories are paginated. Replace by id, which equals campaignCreatorContractHistoryId. Requires X-Application-Id, X-Api-Key, and campaigns:read. Follow the shared syncing workflow for pagination, cursor storage, retries and removals. Only cursor and limit are accepted.
On subsequent requests, add --data-urlencode "cursor=$SAVED_CURSOR".

Record format

Each item in data is a complete replacement with these fields:
termsSnapshot contains the complete stored contractual terms, interpreted according to schemaVersion. The example above is a valid version with no active payment components. The contract history endpoint presents these terms in its public display format. semanticHash describes those terms. This feed excludes internal author IDs, repair references, and audit reasons outside the terms snapshot. Versions include future effective dates, superseded/voided versions, and previous contract instances for available memberships. isCurrentInstance identifies the membership’s current instance; it does not mean that the version governs every upload or is already effective. contractInstanceState is OPEN or CLOSED; version status is ACTIVE, SUPERSEDED, or VOIDED. Keep effective dates locally. A future version is delivered when created; merely reaching that date does not change the stored version or emit a new record. Contract terms are governed by upload dates and the returned campaign/agency timeZone, not just the polling date. Use the existing contract read and payout preview endpoints when you need Grade’s current interpretation or payable value. Edits, retirement, replacement, instance closure, changes to the current instance, and timezone changes produce replacements. A superseded version stays in the feed with its status; physical deletion or an unavailable membership produces a removal. A membership without history contributes no version records.

Stored terms schema

termsSnapshot is the versioned stored contract, distinct from the display contract object on the contract-history list. Persist the entire object, including fields added in later schema versions. An inactive component has active: false; its other fields can be null. Contractual decimal values in the stored snapshot are strings. Do not derive payout totals by applying only part of the snapshot. Grade’s payout preview accounts for the full rules, upload dates and settlement history.