Not yet implemented
Idempotency keys, rate limiting, and the operations the SDK deliberately does not expose.
Three kinds of gap, kept on one page so it is clear which is which: behaviour the SDK is built forward-ready for, operations the API declares but the SDK does not expose, and one error type nothing raises yet.
Idempotency keys
Current behaviour. Writes — subscriptions->create(), cancel(), updateBillingCycle() — 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 cancellation — 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.
What changes when they 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. The API does not enforce a published quota today. RateLimitError exists, is mapped from a 429, and carries retryAfter in seconds when the server sends the header.
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. If a RateLimitError still reaches you, the retries are exhausted; back off using $e->retryAfter when it is non-null.
Retry-After is read as seconds only. An HTTP-date value is ignored, and so is a negative one; computed backoff applies instead.
Operations the SDK does not expose
The API specification declares these; the SDK does not surface them, and a call site written against them will not compile.
| Operation | Instead |
|---|---|
subscriptions_resume | No resume(). |
subscriptions_read | No single-subscription retrieve() — filter a list() page, or read the record you already hold. |
customers_create, customers_partial_update | Customers are read-only; a record is created implicitly by subscriptions->create(). |
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.