Skip to main content
Features

Location filter on product availability

Product availability accepts an optional location_id, so only items at that Shopify location count toward a variant’s availability. It matches the location_id filter already on the availability timeline.
Check availability at one location
The filter applies only when locations are turned on for the store, and is ignored otherwise. Leave it out to count items at every location, as before. Oversellable variants stay available whatever the location.
Features

Oversellable variants in availability

The availability log and availability timeline responses include oversellable, which is true when the variant is set to keep selling past the items in stock.When it’s true, read inventoryCount as a count rather than a cap. The variant stays bookable on dates where every item is already out, and no inventory count limits the quantity. The earliest start date still comes from the delivery method, so the opening entry of the availability log is unchanged.Merchants turn this on per variant with Allow overselling. See Overselling items.
Features

Delete a blocked date

DELETE /api/v1/blocked_dates/{id} removes a manually blocked date range and restores availability for the item, variant, or product it covered. Listing, fetching, and creating blocks were already on the API, so a block can be raised and cleared without opening the admin.
Delete a blocked date
The endpoint is scoped to your shop and skips the blocks Supercycle creates for cycle scheduling, matching GET /api/v1/blocked_dates/{id}. A delete returns 204 with no body, and an ID outside your shop returns 404.
Improvements

Blocked dates in the shop timezone

GET /api/v1/blocked_dates reads from and to in the shop’s timezone, and anchors the activeFrom and activeTo filters to shop-local days.A block covering January 1 to January 7 in a New York store returns those dates, and a window filter over the same range matches it.
Improvements

Lead time enforced on intents

Creating an intent with a start date inside the delivery method’s lead time returns 422 with the earliest date you can book.
Response
The floor is the one the storefront calendar draws, so a cached theme asset or a request built by hand gets the same answer as a shopper picking dates. A leg with no start date of its own, such as a membership, resale, or trade-in, is unaffected.
Improvements

Remove tags through the API

tagsAttributes entries match the record’s existing tags by title, so an entry with _destroy: true removes the tag with that title from a cycle or a return.
Remove a tag from a cycle
Sending a title the record already carries leaves the tag as it is, an explicit id takes precedence over the title, and removing a title the record doesn’t carry is a no-op. tagsAttributes is documented on PUT /api/v1/return_orders/{id} as well as PUT /api/v1/cycles/{id}.
Improvements

Condition and pick location on new items

POST /api/v1/items applies conditionId and pickLocation when it creates the item, as PUT /api/v1/items/{id} already did, so an item arrives ready to use without a second call.
Create an item with its condition and pick location
A quantity above 1 applies both fields to every item in the batch. A conditionId from another shop returns 404, the same as on update.
Improvements

Cycle as the resource type

Cycles are stored as Cycle, so the timeline comment eventableType and the custom field ownerType report Cycle where they reported Rental. Rows created before the change can still come back as Rental, so read the two as the same resource.Rental is still accepted on requests, with no end date on it, so an integration that posts "eventableType": "Rental" keeps working.
Improvements

Filter cycles by fulfillment date

GET /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.
Cycles fulfilled in a week
Improvements

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] 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.
Features

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 for that cycle, or pass null to revert to the automatic date.
Override the preparation date
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 and the Update cycle Shopify Flow action.
FeaturesImprovements

Blocked dates on the Admin API

List, fetch, and create manually blocked date ranges on items, variants, and products through the Admin API. 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.
Create a blocked date
  • 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.
FeaturesImprovements

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.
Rentals received in a week
  • 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.
Features

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.
Deprecation

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 endpoint. To migrate early, or to delay the migration, contact support from the app.
Improvements

Item location on the Admin API

Get and update an item’s location through the Admin API. Keep an external WMS or OMS in step with where each unit lives, without anyone editing locations by hand in the admin.
Features

Create timeline events via the Admin API

Add comments to an item, rental, or return through the Admin API. 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.
Features

Storefront API in beta

The Storefront API 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.