> ## Documentation Index
> Fetch the complete documentation index at: https://docs.supercycle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API changelog

> Updates to the Supercycle Admin API and Storefront API

<Update label="August 4, 2026" tags={["Improvements"]} rss={{ title:"Filter cycles by fulfillment date",description:"GET /cycles accepts a fulfilledAt date-range filter for the actual fulfillment timestamp." }}>
  ## Filter cycles by fulfillment date

  [`GET /cycles`](/api-reference/admin/cycles/list-all-cycles), and the deprecated `/rentals` alias, now accept a `fulfilledAt` filter with the `gte`, `gt`, `lte`, and `lt` operators for the actual fulfillment timestamp, alongside the existing `receivedAt`, `receiveAt`, `rentalStart`, `created`, and `updated` filters.

  Query the cycles fulfilled in a window to sync dispatch records to an external system, or to report on what shipped in a period.

  ```text Cycles fulfilled in a week theme={null}
  GET /api/v1/cycles?fulfilledAt[gte]=2026-08-01T00:00:00Z&fulfilledAt[lt]=2026-08-09T00:00:00Z
  ```
</Update>

<Update label="August 4, 2026" tags={["Improvements"]} rss={{ title:"Incremental sync picks up leg changes",description:"updated[gte] now includes cycles when only their fulfillment or receival fields changed." }}>
  ## Incremental sync picks up leg changes

  Fulfillment and receival timestamps live on leg rows, not on the cycle row. When a cycle is marked fulfilled or received, Supercycle now bumps the cycle's `updatedAt`, so an [`updated[gte]`](/api-reference/admin/cycles/list-all-cycles) incremental sync catches the change even when no other cycle field was written.

  If you poll with `updated[gte]`, cycles that become fulfilled or received appear in the next page without a separate `fulfilledAt` or `receivedAt` filter.
</Update>

<Update label="July 9, 2026" tags={["Features"]} rss={{ title:"Override prepare from and restock by dates",description:"PUT /rentals/{id} accepts prepareFrom and restockBy to override the shop's logistics buffers for a single cycle." }}>
  ## Override prepare from and restock by dates

  `PUT /api/v1/rentals/{id}` now accepts `prepareFrom` and `restockBy` alongside the existing scheduling fields. Set either to override the date computed from the shop's [logistics buffers](/documentation/configuration/logistics/buffers) for that cycle, or pass `null` to revert to the automatic date.

  ```text Override the preparation date theme={null}
  PUT /api/v1/rentals/123
  {
    "prepareFrom": "2026-07-14",
    "restockBy": null
  }
  ```

  The override holds until the leg's anchor date (`fulfilledAt` or `receivedAt`) next moves, when Supercycle recomputes both dates from the shop's buffers. Values outside the receive and fulfill bounds are accepted. A date that can't be parsed returns `422` with the reason in the response body.

  The same fields are on the [`update_cycle` MCP tool](/ai/operators-mcp/tools#cycles) and the [**Update cycle** Shopify Flow action](/documentation/manage/automation/automation#available-actions).
</Update>

<Update label="June 24, 2026" tags={["Features","Improvements"]} rss={{ title:"Blocked dates on the Admin API",description:"List, fetch, and create blocked dates on items, variants, and products." }}>
  ## Blocked dates on the Admin API

  List, fetch, and create manually blocked date ranges on items, variants, and products through the [Admin API](/api-reference/admin/introduction). Rental scheduling blocks are excluded, matching the blocked dates index in the admin.

  `GET /api/v1/blocked_dates` lists blocks, with filters for `resourceType`, `itemId`, `shopifyVariantId`, `shopifyProductId`, `activeFrom` and `activeTo` (overlap with a calendar window), `search` on the description, and `created` and `updated` date ranges. `GET /api/v1/blocked_dates/:id` returns one block with its resource details.

  `POST /api/v1/blocked_dates` creates a block from `resourceType`, `resourceId`, optional `from` and `to` dates, and an optional `description`. Open-ended ranges, with no `from` or no `to`, are supported.

  ```text Create a blocked date theme={null}
  POST /api/v1/blocked_dates
  {
    "resourceType": "Item",
    "resourceId": 123,
    "from": "2026-01-01",
    "to": "2026-01-07",
    "description": "Maintenance"
  }
  ```

  <Accordion title="Improvements">
    * **Sub-day buffer durations.** Shop logistics settings expose `preparationDuration` and `restockDuration` as serialized durations, for example `6.hour` or `2.day`, instead of whole-day integers, so sub-day buffers can be set through the API.
    * **Consignor custom fields.** Custom field definitions accept `owner_type=consignor` when consignment is turned on for the store.
  </Accordion>
</Update>

<Update label="June 9, 2026" tags={["Features","Improvements"]} rss={{ title:"Filter rentals by receival date",description:"GET /rentals accepts a receivedAt filter for the actual receival timestamp." }}>
  ## Filter rentals by receival date

  `GET /rentals` now accepts a `receivedAt` filter with the `gte`, `gt`, `lte`, and `lt` operators for the actual receival timestamp, alongside the existing `receiveAt`, `rentalStart`, `created`, and `updated` filters.

  Query the rentals received in a window to keep an external system in step with when items came back, not only when they were due.

  ```text Rentals received in a week theme={null}
  GET /api/v1/rentals?receivedAt[gte]=2026-06-01T00:00:00Z&receivedAt[lt]=2026-06-09T00:00:00Z
  ```

  <Accordion title="Improvements">
    * **Charge collector status.** `create_charge` accepts an optional `payment_collector_status`, defaulting to `active`, so you can create a charge whose collection starts in a non-active state.
    * **Subscription contract lines.** Remove a line item from a subscription contract through the Admin GraphQL draft flow.
  </Accordion>
</Update>

<Update label="June 9, 2026" tags={["Features"]} rss={{ title:"Recredit a membership credit",description:"PUT /membership_credits/{id} recredits or reclaims a customer's membership credit when a rental comes back." }}>
  ## Recredit a membership credit

  `PUT /membership_credits/{id}` recredits or reclaims a customer's membership credit when you receive a rental back. It's the same action as in the admin.

  The v1 Rental response now includes a `membershipCredit` object with the credit's ID, cost, status, and return condition, so you can find the credit and its status without a second call.
</Update>

<Update label="February 16, 2026" tags={["Deprecation"]} rss={{ title:"Rental intent tokens are being retired",description:"Plan to migrate off rental intent tokens. Contact support from the app to migrate early or delay." }}>
  ## Rental intent tokens are being retired

  Rental intent tokens are being retired. If your integration creates or reads them, plan to migrate off them to the [Intent](/api-reference/storefront/intent) endpoint. To migrate early, or to delay the migration, contact support from the app.
</Update>

<Update label="May 1, 2025" tags={["Improvements"]} rss={{ title:"Item location on the Admin API",description:"Get and update an item's location through the Admin API." }}>
  ## Item location on the Admin API

  Get and update an item's location through the [Admin API](/api-reference/admin/items/update-an-item). Keep an external WMS or OMS in step with where each unit lives, without anyone editing locations by hand in the admin.
</Update>

<Update label="March 21, 2025" tags={["Features"]} rss={{ title:"Create timeline events via the Admin API",description:"Add comments to an item, rental, or return through the Admin API." }}>
  ## Create timeline events via the Admin API

  Add comments to an item, rental, or return through the [Admin API](/api-reference/admin/timelinecomments/create-a-timeline-comment). Push context from your own systems, such as an inspection note or a 3PL update, onto the record's timeline so the full history lives in one place.
</Update>

<Update label="February 19, 2025" tags={["Features"]} rss={{ title:"Storefront API in beta",description:"Build a fully custom rental storefront with your own availability, cart, and checkout flows." }}>
  ## Storefront API in beta

  The [Storefront API](/api-reference/storefront/introduction) is available in beta on request. Build a fully custom rental storefront with your own availability, cart, and checkout flows. Contact support from the app to request access.
</Update>