Not yet implemented

As of 1.1.0 the SDK exposes every operation the /api/v1 specification declares — the "operations the SDK does not expose" gap this page used to list (subscriptions->resume(), subscriptions->read(), customers->create()/->update()) is closed. What is left is behaviour the SDK is built forward-ready for, and one error type nothing raises.

Idempotency keys

Current behaviour. Writes — subscriptions->create(), cancel(), resume(), renew(), updateBillingCycle(), checkoutSessions->create(), customers->create(), ->update(), and every $suqo->webhooks write — are never retried automatically. GET requests are, up to maxRetries, on a network failure, a timeout, a 429 or a 5xx.

That asymmetry is deliberate: without an idempotency key, a retried write could double-act — a duplicate subscription, a second checkout session — and the SDK cannot tell a request that failed on the way out from one that failed on the way back. A NetworkError on a write means the request may or may not have landed. Reconcile rather than blindly resend.

Two writes are safe to retry yourself without a key, because the API makes them idempotent: customers->create() is an upsert (an existing email or phone corrects that customer and answers 200 rather than 201), and subscriptions->cancel() / ->resume() return the current state unchanged, with a 200, when the subscription is already in the target state.

What changes when idempotency keys ship. The decision lives in one place: Constants::writesRetryable() reads a single constant, and it is asserted to be read in exactly two places. When idempotency keys exist, that constant flips and writes join the retry-eligible set with no other change.

Rate limiting

Current behaviour. checkoutSessions->create() is the one endpoint the API rate-limits today — 20 sessions a minute per account by default. Everything else has no published quota. RateLimitError exists, is mapped from a 429, and carries retryAfter in seconds when the server sends the header, for any endpoint that does start returning one.

A 429 on a GET is retried automatically, and a server-supplied Retry-After is honoured by the retry policy — not jittered, and capped at 60 seconds. checkoutSessions->create() is a write, so a 429 there is not retried for you — see Create checkout sessions.

Retry-After is read as seconds only. An HTTP-date value is ignored, and so is a negative one; computed backoff applies instead.

NotImplementedError

Nothing raises this today. It was what every $suqo->customers method returned before those operations were implemented, and the type is kept as the declared error for a resource added to the client's shape ahead of its operations — so a call site written against a future resource keeps compiling.