HomeGuidesAPI ReferenceChangelog
Terms of Use
Changelog
Terms of Use
Back to All

3.274.0 release notes

about 2 hours ago by ReadMe API
  1. ⚠️ Breaking changes
    1. Changed settlement record creation on POST /public-api/resources/partner-settlement-reports/v1.0/{partnerSettlementReport}/records for reports generated under the collected-revenue-only payout basis: requests now return 409 with errorCode: direction_required_use_v1_1. Use POST /public-api/resources/partner-settlement-reports/v1.1/{partnerSettlementReport}/records and supply direction instead.
    2. Made settlement records immutable for reports generated under the collected-revenue-only payout basis on PUT and DELETE /public-api/resources/partner-settlement-reports/v1.0/{partnerSettlementReport}/records/{PartnerSettlementRecord} and PUT and DELETE /public-api/resources/partner-settlement-reports/v1.1/{partnerSettlementReport}/records/{partnerSettlementRecord}. These operations return 409 with errorCode: records_immutable_for_collected_revenue_only_operator; correct an entry by creating a record with a negative paidAmount instead.
  2. ✨ New features
    1. Added the experimental GET /public-api/resources/churn-reasons/v1.0 endpoint to list available churn reasons, including their names, translations, exit types, applicable subjects and partner category restrictions. Its schema and behavior may change without a version bump while it remains experimental.
    2. Added the optional churnReason object to POST /public-api/resources/partner-invites/v2.0, PATCH /public-api/resources/partner-invites/v2.0/{partnerInvite} and POST /public-api/actions/partner-invite/v1.0/{partnerInvite}/expire, accepting either reasonId or customReason with exitType. Only operator and global tokens may send it; create and update requests require an expiration date, and update requests can send an empty object to remove the stored reason or omit the field to preserve it.
    3. Added the optional boolean isInvoicedExternally to requests and responses on POST /public-api/resources/partners/v2.0 and PATCH /public-api/resources/partners/v2.0/{partner}, and to responses on GET /public-api/resources/partners/v2.0, GET /public-api/resources/partners/v2.0/{partner} and POST /public-api/actions/partner/v1.0/{partner}/set-custom-fields. When true, partner invoices are not issued for the partner's settlement reports and payments are registered on those reports instead; existing invoices are unaffected.
    4. Added payoutBasis and the conditional totals totals.payableRevenue, totals.paidFromEarlierPeriods, totals.earnedThisPeriod and totals.notYetPayable to responses on GET /public-api/resources/partner-settlement-reports/v1.1 and GET /public-api/resources/partner-settlement-reports/v1.1/{partnerSettlementReport}. These fields distinguish all-earned-revenue and collected-revenue-only payouts and, where applicable, show revenue paid out, revenue from earlier periods, revenue earned in the current period and revenue not yet payable.
    5. Added direction, accepting received or paid, to request bodies on POST /public-api/resources/partner-settlement-reports/v1.1/{partnerSettlementReport}/records and PUT /public-api/resources/partner-settlement-reports/v1.1/{partnerSettlementReport}/records/{partnerSettlementRecord}, and to responses from those endpoints and their corresponding collection and single-record GET endpoints. It is required when creating records for reports generated under the collected-revenue-only payout basis, and creation returns 409 with errorCode: direction_total_below_zero if the entry would make that direction's payment total negative.
    6. Added payoutSettlementReportIds to responses on GET /public-api/resources/partner-revenues/v1.2 and POST /public-api/actions/partner-revenue/v1.0/{partnerRevenue}/set-custom-fields, identifying reports that paid out or carried the revenue, oldest first. Added the optional filter[payoutSettlementReportId] query parameter to GET /public-api/resources/partner-revenues/v1.2 to find revenue associated with a payout report.
  3. 🔧 Improvements
    1. Expanded notification types with transactionRefund.changed for subscriptions on POST /public-api/notifications/v2.0 and PUT /public-api/notifications/v2.0/{notification}, and for resend requests on POST /public-api/actions/notifications/v1.0/{notification}/resend. The notifications response array can also contain this value on GET and POST /public-api/notifications/v1.0, GET and PUT /public-api/notifications/v1.0/{notification}, GET and POST /public-api/notifications/v2.0, and GET and PUT /public-api/notifications/v2.0/{notification}.