Use scoped API Keys
Grant only the scopes required by the integration path.
Integrate with Tenzarch as a server-side execution dependency.
Production integrations should protect API Keys, submit workloads idempotently, store execution references, handle asynchronous lifecycle states, and monitor credits and failures.
The stable production path is explicit and repeatable.
01Create developer profile
02Create scoped API Key
03Store key server-side
04Discover AI Executions
05Submit with Idempotency-Key
06Persist jobId
07Track lifecycle
08Read result, logs, telemetry
Minimum production checklist before launch.
Send idempotency keys
Protect retries from duplicate Jobs, duplicate Workflow Runs, and duplicate initial credit charges.
Handle async lifecycle
Do not expect the execution request to return a final AI result synchronously.
Handle credit and rate failures
Treat insufficient credits, conflict responses, and throttling as normal production states.
Rotate compromised keys
Disable, revoke, or rotate API Keys immediately if they are exposed.
Use the SDK for typed execution operations.
Server-side setup
import { Tenzarch } from "@tenzarchsdk/sdk";
const tenzarch = new Tenzarch({
apiKey: process.env.TENZARCH_API_KEY!,
baseUrl: process.env.TENZARCH_API_URL!,
});The SDK improves ergonomics around service discovery, execution submission, Jobs, pagination, telemetry, usage, idempotency, retries, cancellation, and structured errors. It does not replace backend state.
Execution Credits are part of the production request boundary.
Developer and user workloads can require Execution Credits before the backend accepts execution demand. Credits are usage accounting for workload execution. They are separate from Node Points, Node Rewards, and any future token-related program.
Check balance
Read account credit state before presenting a production execution flow.
Charge on acceptance
A credit charge belongs to accepted execution demand, not to every client-side retry attempt.
Use idempotency
A repeated request with the same logical intent should reuse the same Idempotency-Key.
Separate reward accounting
Do not mix Execution Credits with Node Points or Node Rewards copy.
Production clients should handle expected platform states deliberately.
Authentication required
Ask the user to reconnect their wallet or use a valid server-side API Key.
Insufficient credits
Route the user or operator toward credit purchase or balance management.
Idempotency conflict
Do not reuse an idempotency key for materially different request bodies.
No eligible node
Treat capacity unavailability as a real execution-network state, not as a generic application crash.
The integration should preserve jobId, workflowRunId, requestId, error code, and timestamps where available so support and debugging can work from exact execution records.