Email verification at signup: blocking sends vs. test mode
Most transactional email providers require your own account email to be verified before you can send anything, which creates an awkward ordering problem for a developer trying to build an integration: you need to send a test email to build the integration, but you can't send until you're verified, and verification itself usually happens over email.
How Envello handles it
API keys carry a mode (test or live, encoded directly in the key itself, env_test_... vs env_live_...), and only live-mode sending requires your account email to be verified first. Test-mode keys work immediately after signup, before verification completes, specifically so you can start building and testing your integration without waiting on an email round-trip you haven't set up yet.
Why this ordering makes sense
Test mode is explicitly not for sending real email to real recipients, it's the sandbox where you confirm your request shapes and integration logic work before anything touches a real inbox. Gating that on verification would just add friction to the part of the process that's lowest-risk. Live-mode sending, the part that actually affects deliverability and reaches real recipients, is where the verification requirement actually matters.
What test mode actually validates
A test-mode request goes through the same validation as a live request, payload shape, required fields, domain format, so you catch integration bugs before they'd affect a real send. What it doesn't do is attempt delivery: the response looks like a real accepted send, webhook events fire the same way, but nothing reaches an SMTP server or a real inbox. This means your webhook handler, retry logic, and error handling are all fully testable before you're verified or have a live-mode key at all.
If the verification email itself doesn't arrive
This is the actual bootstrapping edge case worth planning for: what if the verification email, sent by the provider you're evaluating specifically because you want reliable transactional email, doesn't reach you? Check spam folders first, then use the resend option in the dashboard, which is rate-limited to prevent abuse but not blocked outright. If it still doesn't arrive, that's worth treating as a signal about the provider's own deliverability before you commit further, not just an inconvenience to work around.
Keeping test and live keys separate in your codebase
Store test and live API keys under different environment variable names (ENVELLO_TEST_KEY vs ENVELLO_LIVE_KEY, or similar) rather than swapping one variable's value between environments, so a misconfigured deploy can't accidentally send real email from a staging environment, or silently no-op in production because a test key ended up there by mistake. The key's own prefix (env_test_ vs env_live_) is also worth asserting against in a startup check, failing loudly if a live key shows up where a test key was expected.
What this means for your own signup flow
If you're building a product with a similar verify-before-full-access pattern, the same principle applies: figure out which parts of your flow are genuinely risky if done by an unverified account (sending real email to third parties, spending money, anything customer-facing) versus which parts are safe to allow immediately (configuration, testing against a sandbox). Gating everything equally, including the low-risk parts, just adds friction without reducing the actual risk you're trying to manage.