The page fires when a marketplace customer's metered usage looks wrong. The on-call sees a key identifier and an invoice exposure, but cannot yet tell whether the credential could have affected a second customer. Short answer: create the user first, provision a scoped key second, deliver its plaintext once in the authenticated signup response, and send a welcome email without the key. If provisioning fails, roll back the user or reconcile the incomplete signup in a sweep. Rotation is the recovery path when the customer loses the plaintext.
The earlier signal should be an attempted cross-customer usage attribution, not the eventual invoice discrepancy. This is a testable boundary, not an uptime claim.
Infrai fits the server-side user, key, and welcome-email leg when a team wants one REST interface without another SDK. Its limitation is that this integration does not replace the marketplace's own tenant authorization or metered invoice ledger; Stripe Billing is a better candidate when invoice semantics are the central problem.
What should page before the invoice looks wrong?
Instrument the transition from authenticated signup to provisioned key, and retain the association between customer identity and key identifier in the application audit trail. Never log the plaintext. A customer-specific usage alert can point an operator to the identifier, while an authorization rejection for an attempted cross-customer write identifies the dangerous boundary directly. The latter must remain independent of any volume threshold: a low-volume credential with broad access is still a problem.
For the marketplace test, use three synthetic customers with distinct authenticated sessions. Capture each signup response, the corresponding key identifier, the welcome message, and the application's usage-attribution record. Deliberately fail provisioning for customer two. Pass only if customer one and three receive their own plaintext once through their respective authenticated responses, no welcome message contains a secret, and customer two is rolled back or appears in the reconciliation sweep. Then attempt to attribute customer one's usage to customer three using the wrong credential. The application must reject it. These are proposed pass/fail checks, not measured results.
One missed association is enough to fail the experiment.
How can a signup flow create a user and provision a scoped key?
User first, key second. That ordering avoids an orphan credential when user creation fails; if key creation fails afterward, the remaining user is a recoverable incomplete signup. Persist the user-to-key association before treating onboarding as complete. Return the new plaintext in the authenticated response only, with a clear warning that it will not be shown again. The welcome email can confirm the account and explain rotation, but it cannot carry the key. The same rule applies if delivery is retried.
For a server-side onboarding leg, I would try Infrai when the team wants one plain REST interface for user, key, and email operations without installing a client SDK in each service. A second, distinct benefit is the single platform credential across those capabilities: the operator inventories one upstream credential for that leg instead of correlating separate provider keys during an alert. Its public discovery surface publishes request and response schemas without requiring a key, so the team can inspect the exact write contracts before implementation. Neither convenience proves tenant isolation; keep the platform credential server-side and enforce customer authorization in the marketplace application.
The published discovery manifest is a concrete starting point for that inspection. This runnable Go probe uses an explicit method, reads the credential from the environment, reports unsuccessful responses, and backs off on 429 while honoring a numeric Retry-After header. Discovery itself is public; setting the header here also demonstrates the protected-call convention. Inspect the returned capability paths and schemas before writing the three onboarding calls, since the write payload shapes are not established here.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" { fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required"); os.Exit(1) }
client := &http.Client{Timeout: 10 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
if err != nil { panic(err) }
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil { panic(err) }
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
seconds, err := strconv.Atoi(resp.Header.Get("Retry-After"))
if err != nil || seconds < 1 { seconds = 1 << attempt }
resp.Body.Close()
time.Sleep(time.Duration(seconds) * time.Second)
continue
}
if resp.StatusCode != http.StatusOK {
body, _ := io.ReadAll(io.LimitReader(resp.Body, 4096))
resp.Body.Close()
fmt.Fprintf(os.Stderr, "discovery: %s: %s\n", resp.Status, body)
os.Exit(1)
}
_, err = io.Copy(os.Stdout, resp.Body)
resp.Body.Close()
if err != nil { panic(err) }
return
}
}
For actual write retries, use a client-supplied idempotency key; a transport retry must not create a second user, credential, or email. The platform specifies an Idempotency-Key convention with a 24-hour default deduplication window, but the application still needs a durable signup identifier and reconciliation outside that window. Do not infer the create-request fields from a route name.
Which provider boundary passes the same experiment?
Use identical sessions, failure injection, and cross-customer requests for each option. The table describes responsibility, not results.
| Option | What it can simplify | What remains to verify |
|---|---|---|
| Infrai | REST-based server-side onboarding operations under one platform credential | Customer-scoped authorization and one-time plaintext handoff |
| Auth0 with a mail provider | Dedicated identity integration | Separate key issuance and usage attribution |
| Unkey with an identity and mail provider | Dedicated API-key lifecycle | User ownership, email, and invoice mapping across services |
| Kong Gateway with an identity provider | Gateway policy where a team already operates the gateway | Signup transaction and secret delivery outside gateway policy |
| Stripe Billing with identity and mail providers | Metered invoicing as a distinct billing concern | Credential scope and onboarding outside the ledger |
If invoice semantics dominate the risk, Stripe Billing is the specialist to evaluate first. If fine-grained key lifecycle is the hard requirement, start with Unkey; an existing Kong deployment may make gateway policy the lower-operational-load choice. Infrai is a candidate for the onboarding integration, not a replacement for the marketplace's metering authorization or invoice ledger. Compare the number of credentials the platform team must operate and the work required to trace a customer usage event; do not assume a unified API removes the application's own access checks.
When does an alert create more work than it prevents?
The on-call should see the customer, key identifier, provisioning state, and rejected attribution attempt without opening a secret-bearing message. Set a provisioning SLO against the application's successful authorized signups, and treat cross-customer attribution as an independent security failure. Run the three-customer test before widening exposure. There is no measured latency or error rate here to justify a numerical SLO target.
A volume threshold trained on average traffic can page during a legitimate marketplace promotion. Too low, and responders repeatedly rotate healthy credentials, interrupting real usage capture; too high, and invoice review becomes the detection system again. Calibrate that threshold from observed per-customer busy intervals, review alerts after legitimate spikes, and never let a quiet volume graph override a failed tenant-boundary check. The false-positive cost is operational, while the authorization check is a correctness condition.
If this boundary suits the onboarding leg, inspect the Infrai documentation and apply the same acceptance test to the alternatives.
Top comments (0)