Skip to main content
The Experimental API is versioned with dates. Pin a version when you want a stable API contract; official SDKs send the version they were generated against automatically.
If you don’t pass an Api-Version-Date, the stable API model is used. Requests without the header are served by the pre-versioning behavior, so existing integrations keep working unchanged. Pin a dated version to opt into the latest API.
New endpoints and new optional fields are added to every version automatically. Breaking changes create a new dated version and are listed below.

​
Changelog

​
Latest
Members and memberships
Members and memberships now use native resources with an account-oriented membership model and redesigned lifecycle actions.
  • Membership responses return plan_id and product_id instead of nested plan and product objects.
  • Listing memberships returns everything the caller can read — their own plus their managed accounts’ — and account_id/user_id narrow that list instead of switching modes or erroring.
  • Set cancel_at_period_end to schedule cancellation; the cancel action ends access immediately.
  • The extend action replaces add_free_days.
​
REST response and timestamp consistency
The Experimental API now uses consistent delete responses, timestamp inputs, and Account naming.
  • Delete endpoints for products, plans, checkout configurations, ads, ad groups, ad campaigns, social accounts, and bounty submissions return { id, deleted: true } instead of a bare boolean.
  • Timestamp filters on products, plans, checkout configurations, transfers, and financial reports accept ISO 8601 only instead of also accepting epoch seconds.
  • Product responses return account instead of company.
​
Partner business payout percentages
Partner businesses now expose separate payout rates for every income source.
  • payout_percentage is replaced by payout_percentages.
  • The nested object includes sales, ad_spend, transfer, and card_interchange rates.
​
Products and checkout configurations
Products and checkout configurations now use the Account model consistently.
  • Product request parameters use account_id instead of company_id.
  • Checkout configuration requests use account_id at the top level and inside inline plan objects.
  • Checkout configuration responses return account_id instead of company_id.
​
Checkout configuration timestamps
Checkout configuration timestamps now use the same format as the rest of the API.
  • created_at and updated_at are ISO 8601 strings instead of Unix epoch integers.
​
User balances
User balances now provide a complete, structured balance summary.
  • The flat total_usd and balances fields are replaced by a nested balance object.
  • The summary separates cash, crypto, in-flight treasury deposits, and balances for accounts the user owns.
​
Business referral earnings resources
Business referral earnings now identify the polymorphic resource that generated the earning.
  • receipt is replaced by resource.
  • access_pass is replaced by product.
  • Receipt-backed earnings return resource.object: "receipt" with receipt payment details.
  • The resource field can support additional earning resources in future versions without reusing receipt-specific fields.
​
Business referrals resource
Business referral volume and earnings are now reported as reconciling groups.
  • processing_volume, total_earnings, pending_payout, and completed_payout are replaced by nested volume_usd and earnings_usd objects.
  • Earnings rename base_amount/amount to transaction_amount_usd/commission_amount_usd and express payout_percentage as a fraction.
​
Plans resource
Plans now use the Account model consistently.
  • Request parameters and request bodies use account_id instead of company_id.
  • Plan responses return account instead of company.
​
Users resource
User access requests now use the Account model consistently.
  • Request parameters and request bodies use account_id instead of company_id.
  • Response shapes are unchanged.
​
Original version
The original Experimental API behavior before dated versioning existed.Requests without Api-Version-Date use this version so existing integrations keep working.