Skip to main content
Configure a TapAce client once and reuse it across requests in your server application. Each resource uses the same HTTP configuration.
maxRetries must be a non-negative safe integer. timeoutMs must be between 1 and 2,147,483,647 milliseconds. Each attempt has its own timeout, including response-body consumption. A custom fetch must honor the provided abort signal. Do not append /v1 to baseUrl; resource methods already include that segment. Unlike the HTTP reference’s base URL, this option expects the origin.

Environment

tapace.environment and tapace.mode both return "test" or "live", detected from the key prefix. They do not change the API origin or create isolated templates. Use tapace.me.retrieve() to confirm the authenticated organization and environment before running a job. A correctly prefixed key can still be revoked or invalid. Keep clients for different organizations or environments separate, and never replace a shared client’s credentials during a request. Test passes are isolated from live passes, but templates, assets and event details are shared. Use a dedicated template for integration tests that change a design or event.

Per-operation options

Mutating methods accept { idempotencyKey?: string } as their final options argument. Methods with an optional parameters argument may need {} before options:
Here templateId and deploymentJobId are values supplied by your application. Timeout and retry settings are client-wide; the current per-operation options do not expose a timeout, cancellation signal or retry override.

Custom fetch

Use a custom fetch for controlled transport integration or tests:
Preserve the supplied signal and headers. Avoid logging authorization headers or complete request bodies containing holder details. See Errors and retries.