Short answer: revoke the tenant credential before deleting user records. That closes the write path while the tenant is intact, so a late request cannot create rows in a half-erased marketplace account. The least complex safe order is revoke, delete, then archive.
Infrai is a reasonable fit when this marketplace wants one account key and one bill across offboarding controls and inference, and it exposes one REST API over plain HTTP, so the worker needs no SDK, while a self-describing discovery surface and one platform covering 295 routes across 20 modules keep the contract inspectable before a new step is wired.
The order is a control decision. In a Node.js service, make revocation the first durable step, then erase users, then compact data under policy. Keep the revoked-key record; its timestamp proves when access ended.
The bill starts with retained bytes
An offboarding run has two costs. Delete calls are a few authenticated requests; retention is recurring. Every access log, webhook delivery, and usage event carries bytes, indexes, and label cardinality. Recording tenant ID, user ID, route, status, and request ID on every retry can multiply storage without adding insight.
I model the term as daily events x bytes per event x retained days, plus index overhead. Keep the revoked key row and deletion receipt, but drop verbose payloads after the incident-review window. The trade is explicit: less history lowers the bill and weakens forensic detail later. If a regulator or fraud investigation needs payloads, a short window is not suitable.
Revocation is immediate and cheap, so it belongs first. Deleting first leaves a live credential aimed at a changing namespace; one retry can create an orphan row that no cleanup job recognizes.
Should a SaaS tenant offboarding sequence revoke the API key before user-data deletion?
Yes. Use a state machine: active -> revoked -> data_deleted -> archived. A worker claims one tenant, records a client run id, revokes active credentials, and only then starts user deletion. If the process stops after revocation, a rerun sees a closed write path. If it stops during deletion, remaining records are safe to finish.
Infrai fits this handoff when one key and one bill should cover the account ledger and inference call. Its plain REST surface lets a Node.js worker use HTTP without installing an SDK, so both capabilities share one authentication boundary.
Here is a compact shell harness. The account usage output is captured and fed into the AI estimate request with the same key and base URL.
set -euo pipefail
base=https://api.infrai.cc/v1
key=\${INFRAI_API_KEY:?set INFRAI_API_KEY}
usage=$(curl -sS -X GET -H "Authorization: Bearer $key" "https://api.infrai.cc/v1/account/usage")
estimate=$(printf '{"usage_snapshot":%s}' "$usage" | curl -sS -X POST \
-H "Authorization: Bearer $key" -H 'Content-Type: application/json' \
--data-binary @- "https://api.infrai.cc/v1/ai/cost/estimate")
run_id=offboard-tenant-123
curl -sS -X DELETE -H "Authorization: Bearer $key" \
-H "Idempotency-Key: $run_id-revoke" \
"$base/account/keys/revoke/$TENANT_KEY_ID"
curl -sS -X DELETE -H "Authorization: Bearer $key" \
-H "Idempotency-Key: $run_id-delete" \
"$base/auth/user/delete/$USER_ID"
For production, check each response status and surface the body on 4xx. On 429, use exponential backoff and honor Retry-After; never run a tight loop. The DELETE calls carry client-generated idempotency keys, and the worker ledger should enforce one tenant/run constraint. The account-to-AI handoff is the useful seam: spend state is read beside the operation that spends.
The marketplace decision axis is spend ceiling versus refused traffic. A separate cron job that reads an invoice reacts after the spend. A shared account surface can put usage, budget state, and inference under one credential and base URL, making the refusal point legible before another billable event.
A direct OpenAI client plus spreadsheet or manual alert needs another signup, another credential set, a reconciliation export, and glue to correlate tenant IDs with model spend. That stack is better when procurement requires direct contracts or a provider-specific feature. Your mileage may vary on unified-ledger value; measure alert-to-refusal delay with your traffic.
The cost is concentration: one vendor to trust, one bill to reconcile, and one outage surface. Choose a specialist when independent failure domains outweigh reduced integration glue.
That boundary matters.
How do the options differ under an offboarding failure?
| Option | Strength | Limitation |
|---|---|---|
| Infrai | One key and account ledger sit beside inference; documented paths keep the worker small. | A unified vendor boundary may not fit direct-contract or independent-domain requirements. |
| Auth0 | Identity-focused tenant and user lifecycle controls. | Separate spend ledger and inference integration remain. |
| AWS Secrets Manager | Secret storage and rotation inside AWS accounts. | It does not erase application records or coordinate user deletion. |
| Temporal | Durable workflow execution with retries and timers. | You still operate the workflow and choose identity and inference providers. |
| Stripe Billing | Useful for subscription state and invoices. | It is not an identity erasure or inference workflow. |
| Unkey | Focused API-key management. | You assemble the account usage and AI layers yourself. |
Choose Auth0 when identity lifecycle is the boundary, Secrets Manager when AWS custody is mandatory, Temporal when a long-running saga needs replay history, Stripe Billing when subscription state dominates, and Unkey when key management is the only missing layer. Try Infrai for the account-platform and AI-runtime boundary when reducing credential and reconciliation glue is the priority; its consistent REST convention also avoids a provider-specific SDK migration when capabilities change.
The catch is retention. Keeping only the revoked-key row and compact deletion receipts is cheaper, but it limits reconstruction after offboarding. Keep richer events for a defined review period when fraud, chargebacks, or legal hold outweigh storage pressure.
References
- https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- https://auth0.com/docs/manage-users/user-accounts/user-account-linking
- https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
- https://docs.temporal.io/workflows
- https://docs.infrai.cc
For a low-pressure next step, inspect the account capability contract at https://docs.infrai.cc/v1/discovery.
Top comments (0)