Scheduled pricing change cannot be replaced or cancelled via API — notice period should restart from the newest change

[myagizmaktav]

A scheduled (not yet active) pricing change cannot be replaced, and there is no way to cancel one. The result is that the first price change you schedule locks the Actor's pricing for the whole notice period, even though nobody has been charged under it yet.

What happens

pricingInfos on an Actor accepts a new record appended to the existing list, and for a published Actor that record must start in the future to respect the notice period. So far so good. But:

1. Adding a second future record is rejected:

PUT /v2/acts/<actorId>   {"pricingInfos": [...existing, newRecord]}
-> 400 cannot-add-second-future-pricing-info
   "There is already a pricing record starting in the future. You cannot add another one."

2. Replacing the pending record — submitting the list without it — is also rejected:

PUT /v2/acts/<actorId>   {"pricingInfos": [...existingMinusPending, newRecord]}
-> 400 incorrect-pricing-modifier-prefix
   "The pricing modifier must start with the existing pricing info objects and then it can
    have optionally one more object you are adding."

3. There is no endpoint to cancel it. DELETE /v2/acts/<id>/pricing-info, /pricing-infos and /scheduled-pricing all return 404 page-not-found.

So a pending change can only be waited out, or cancelled by hand in the Console.

Why this is a problem

The notice period exists to protect users who are already being charged under the current price. A record that has not started yet has charged nobody, so there is nothing to protect — but it still blocks every further change for the length of the notice window.

Concretely, what happened to us today on instagram-stories-scraper-v2: we scheduled a straightforward per-result price rise, then measured the Actor's real unit economics a couple of hours later and found the per-result model was structurally wrong for this surface. Stories expire after 24 hours, so the backend spends the same lookup cost per username whether or not that account currently has a story, and in our sample only 2 of 8 accounts did. Charging per returned story alone therefore loses money on every empty lookup; the correct fix is a two-event model (charge the lookup, plus charge per story). We have the code deployed for it, but we cannot schedule the pricing, because the earlier, now-obsolete record is pending. The better model is delayed by two weeks for no user-facing reason.

Request

Let a pending pricing record be superseded, with the notice period restarting from the new submission. In other words: if I schedule a change that activates in 10 days and then submit a different change on day 5, the day-5 change should replace the pending one and activate 10 days from day 5 — users still get the full notice, and I am not locked into a price I have already learned is wrong.

Either shape works for us:

• allow pricingInfos to be submitted with the pending (future, never-active) record replaced, or
• expose a way to cancel a scheduled change via the API, so the normal append path can be used again.

If the current behaviour is deliberate, it would help to document it on the monetization page, along with the fact that cancelling a scheduled change is Console-only — right now both constraints are only discoverable by hitting the two errors above.

Account for reference: myagizm.