Rate Limits and Idempotency

When working with the Control Plane, it is useful to separate two topics:

• account-level product limits;
• automation resilience to network failures and repeated calls.

Product limits

On the trial plan, hard limits apply to the number of tenants, databases, compute time, and egress. Therefore, when building mass automation, account for the plan your account is using in advance.

Idempotency: the safe practical approach

For API v2, it is better not to build critical automation on the assumption that every write operation supports a special Idempotency-Key. In the current user contract, it is more useful to follow a more reliable pattern:

1. send the write request;
2. if the result is uncertain, read the resource state again;
3. only then decide whether a retry is needed.

Why this matters

Creating and deleting resources in SPG99 can be asynchronous. That means the same object may stay in creating or deleting for some time, and a blind retry only makes automation more confusing.

A good strategy

• use GET as the main source of truth after any questionable write operation;
• log the payload and the API response;
• do not repeat destructive actions until you verify state;
• design automation to tolerate 409 Conflict and LimitExceeded.

This approach is usually more reliable than trying at all costs to build a “perfectly idempotent create” on top of a dynamic serverless catalog.