Node and Express transactional send
Add a POST /receipts/:orderId endpoint to my Node.js Express app. Install the official SDK with npm i @blitzglobaltech/pulsepigeon. Read PULSEPIGEON_API_KEY from the server environment and fail startup if it is missing; never put the key in source, logs, browser code, or a URL. Construct new PulsePigeon(process.env.PULSEPIGEON_API_KEY). Use client.messages.send with project_id, from_email, to: [{ email }], subject, text, and category: "billing". Set options.idempotencyKey to a stable order receipt event ID. Validate the order and recipient, return the accepted message ID, and distinguish validation, rate-limit, and temporary server errors. Include an Express route and a focused test with the SDK mocked.
Python and FastAPI send
Add a FastAPI endpoint that sends a signup verification email. Install the official Python SDK with pip install pulsepigeon. Read PULSEPIGEON_API_KEY from the server environment, never hard-code or log it, and construct AsyncPulsePigeonClient(api_key=os.environ["PULSEPIGEON_API_KEY"]). Await client.send_message with project_id, from_email, to: [{"email": recipient}], subject, text, and category: "security". Pass a stable signup-event ID as idempotency_key. Validate input, keep the verification token out of logs, return the accepted message ID, and add tests for success and SDK failure.
Password reset with safe retries
Implement a password-reset request flow in my Node.js app using npm i @blitzglobaltech/pulsepigeon. Load PULSEPIGEON_API_KEY from the server environment only and use new PulsePigeon(process.env.PULSEPIGEON_API_KEY). Generate a short-lived, single-use reset token in my app, store only its hash, and send the link with client.messages.send({ project_id, from_email, to: [{ email }], subject, text, category: "security" }, { idempotencyKey: stableResetRequestId }). Keep the same key and payload on retries. Return the same public response whether the account exists or not, rate-limit requests, and avoid logging tokens, links, and API keys. Add tests for replay and account enumeration.
Batch send and per-item failures
Implement a personalized invoice batch worker with npm i @blitzglobaltech/pulsepigeon. Read PULSEPIGEON_API_KEY only from the server environment. Use new PulsePigeon(process.env.PULSEPIGEON_API_KEY) and client.messages.sendBatch(items). Build at most 100 items per call; each item must be { idempotency_key: stableInvoiceRecipientEventId, message: { project_id, from_email, to: [{ email }], subject, text, category: "billing" } }. Inspect response.results and its accepted/failed status per item, persist accepted message IDs, and retry only retryable failed items with their original keys and bodies. Report permanent failures for review. Add a test for a mixed-result batch without duplicate sends.
Verify signed status webhooks
Add an Express POST /webhooks/pulsepigeon handler using npm i @blitzglobaltech/pulsepigeon and import { verifyWebhookSignature } from "@blitzglobaltech/pulsepigeon". Read PULSEPIGEON_API_KEY and the separate webhook signing secret from server environment variables; never expose either. Parse the JSON body, then call verifyWebhookSignature(parsedPayload, req.header("PulsePigeon-Signature") ?? "", webhookSecret). Reject invalid or stale signatures before processing, use the event ID to deduplicate, and acknowledge valid events quickly. Do not hash raw request bytes: the SDK helper verifies canonical JSON. Include valid, invalid, stale, and duplicate tests.
Domain setup and DNS checks
Write a domain-setup checklist for my verified sending domain using pip install pulsepigeon. Keep PULSEPIGEON_API_KEY in the server environment. Use PulsePigeonClient(api_key=os.environ["PULSEPIGEON_API_KEY"]) and client.check_domain(domain_id) to recheck its SPF, DKIM, and DMARC status after I publish the records shown by PulsePigeon. This tenant-wide check needs an owner-created workspace key with domains:* scope and is rate-limited. Also use the public DNS checker at https://pulsepigeon.com/tools/dns-checker to inspect the domain. Explain SPF authorization, DKIM selector records, and a gradual DMARC policy. Show how to report unresolved checks; do not invent DNS values or claim the SDK creates DNS records.
Inbound message handling
Design a server-side inbound-processing job for my app. Install the official Python package with pip install pulsepigeon, but do not invent an inbound SDK method: use the documented REST routes GET /v1/inbound/config, GET /v1/inbound/messages, and GET /v1/inbound/messages/{message_id} with an authorized workspace session. Use the package's verify_webhook_signature(parsed_payload, signature_header, webhook_secret) helper to authenticate inbound event notifications before processing them. Keep the webhook secret separate from PULSEPIGEON_API_KEY, which is for supported SDK operations and must stay in the server environment; do not send it to these session-authenticated inbound routes. Check that inbound is enabled and MX routing is configured before claiming messages will arrive. Deduplicate by message ID, validate sender and recipient, process retained content only when the workspace opted into full-content storage, and handle missing content. Keep credentials out of logs.
Test-mode sandbox first
Add a safe first-send script in Python using pip install pulsepigeon. Load PULSEPIGEON_API_KEY from the server environment only and construct PulsePigeonClient(api_key=os.environ["PULSEPIGEON_API_KEY"]). Require a pre-created test-mode project ID and a key scoped to that project; do not silently fall back to a production project. Read the differences between Test and Live projects at https://pulsepigeon.com/docs/test-vs-live-projects before picking the project mode. Call client.send_message with project_id, from_email, to: [{"email": test_recipient}], subject, text, and idempotency_key="sandbox-smoke-" plus a stable test-run ID. Show how to inspect the sandbox capture and assert no external delivery, then list explicit checks required before changing the project and key to production. Never print or embed the API key.