klaviyo-multi-env-setup

name	klaviyo-multi-env-setup
description	Configure Klaviyo across development, staging, and production environments. Use when setting up multi-environment deployments, configuring per-environment API keys, or implementing environment-specific Klaviyo configurations. Trigger with phrases like "klaviyo environments", "klaviyo staging", "klaviyo dev prod", "klaviyo environment setup", "klaviyo config by env".
allowed-tools	Read, Write, Edit, Bash(aws:*), Bash(gcloud:*), Bash(vault:*)
version	1.7.0
license	MIT
author	Jeremy Longshore <[e-mail]>
tags	["saas","klaviyo","email-marketing","cdp"]
compatibility	Designed for Claude Code

Klaviyo Multi-Environment Setup

Overview

Configure Klaviyo across development, staging, and production with separate API keys, environment detection, secret management, and production safeguards. Every environment follows the same shape — detect the env, resolve its config, load its secret, guard destructive/send operations. The lean workflow and first skeleton live here; full step-by-step code lives in references/implementation.md.

Prerequisites

• Separate Klaviyo accounts or API keys per environment
• Secret management solution (GCP Secret Manager, AWS Secrets Manager, Vault)
• klaviyo-api SDK installed

Environment Strategy

Environment	Klaviyo Account	API Key	Use Case
Development	Test account	pk_test_dev_***	Local development, exploration
Staging	Test account	pk_test_staging_***	Pre-prod validation, integration tests
Production	Production account	pk_live_***	Real customer data, live sends

Important: Klaviyo does not have a sandbox mode. Use a separate test account for dev/staging to avoid sending real emails.

Instructions

The pattern is the same across all three environments; only the API key and the per-env flags change. Read the matching section in references/implementation.md, then:

1. Write the config module — use Write/Edit to create src/config/klaviyo.ts with a detectEnvironment() helper and a per-env ENV_CONFIGS map that flips enableSending, cache, and rate-limit concurrency by environment.
2. Store secrets per environment — create one secret per env in your platform's secret store (gcloud secrets create, aws secretsmanager create-secret, or Vault). Never commit keys; local dev reads a git-ignored .env.local.
3. Add environment guards — wrap sends and deletions so non-production simply logs instead of touching real data (guardCampaignSend, ).