Restore a deleted subscription type
POSThttps://
Clears the soft-delete marker and returns the type in the detail view, which puts it back in the catalogue and gives its existing customer subscriptions their displayed name back.
Access
- Token scope
- api:
write: subscription_types Without it:
403 insufficient-token-scope. - Permission
- subscription_types::
create Without it:
403 insufficient-permission. - Feature
- Needs the billing feature on your organisation.
Without it:
404 endpoint-not-found. - Rate cost
- 1 unit, write bucket. A write costs the same whatever
viewyou ask for. - Also
- Accepts
Idempotency-Key. AcceptsIf-Match. Never cached:private, no-store. Unknown query parameters are refused, never ignored.
Both are checked, scope first. A token never does more than its user. How access is checked
Restoring additionally requires subscription_types::delete as well as subscription_types::create. Restoring a type that is not deleted succeeds and returns an already_in_target_state warning. The restore finds a deleted type on its own, so the trashed parameter is not accepted. The type's template lines were never deleted, so nothing about them changes.
Path parameters
Query parameters
Unknown parameters are refused with 400, naming the parameter.
Request headers
A correlation id of your own. It is recorded in our logs next to the server's request id but never returned: the response header always carries the server's id. A value that does not match the pattern is discarded silently, never rejected.
Response 200
Returns a SubscriptionType in the detail view.
Headers
ETag- A strong validator of exactly this representation.
Idempotency-Replayedtruewhen this response was replayed from a storedIdempotency-Keyrather than produced by a new write.RateLimit- The IETF
httpapi-ratelimit-headersform of your remaining allowance on the tightest bucket this request touched. RateLimit-Policy- The ceiling and window of that bucket, as
<limit>;w=<seconds>. X-Request-Id- The server-generated ULID correlating this response with our logs.
Every response also carries Cache-Control, Vary, X-Content-Type-Options, X-Plnnrly-Api-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Headers and versioning
Subscription type name. It is also the name every customer subscription of this type is displayed under, so renaming a type renames what its existing subscriptions read as. Names are not unique.
Interval a new subscription of this type is billed at by default. Omitting it on create yields yearly, the stored default, not the monthly that plnnrly's form pre-selects, which is a form convenience the API deliberately does not reproduce.
yearlymonthlyone-time
New values may be added.
Whether subscriptions created from this type renew automatically by default. The value is stored exactly as sent; nothing forces it to false.
Whether the type is offered in the catalogue. It is a catalogue flag only: nothing in the application filters on it, so deactivating a type does not stop existing subscriptions of that type from being renewed or invoiced.
Position in the catalogue, assigned by the server on create as one past the highest existing position. It is the default sort key, and there is no way to reorder types through the API: dragging types into order in plnnrly has no API equivalent in v2.0.
Last-write timestamp; use for incremental sync. It also feeds the ETag revision, because a subscription type has no version field.
Errors
409 Conflict.
412 Precondition failed.
7 errors every operation can return: 400, 401, 404, 406, 429, 500, 503
400 Bad request.
idempotency-key-requiredinvalid-cursorinvalid-query-parametermalformed-requestunsupported-parameter
401 Unauthenticated.
404 Not found.
406 Not acceptable.
429 Too many requests.
500 Server error.
503 Service unavailable.
This path allows POST. Anything else answers 405.
Something wrong or missing on this page? Tell us