Staging vs Production at Healthie

Healthie maintains separate Staging (Sandbox) and Production environments. These environments are intentionally isolated, and there is no mechanism to push data, configurations, or code directly from Staging into Production. This separation is foundational to Healthie’s security, compliance posture, and API-first architecture.

Why Healthie Uses Separate Staging and Production Environments

Healthie is an API-first platform. The same APIs used by customers and partners are used internally to power Healthie’s web and mobile applications.

To protect customers, patients, and partners, Healthie operates two completely independent system instances:

• Staging (Sandbox) – for testing, development, and validation
• Production – for live patient data and real-world operations

These environments do not share databases, credentials, or infrastructure.

What this protects against

Maintaining strict separation allows Healthie to:

• Prevent test or malformed data from impacting live patient records
• Protect PHI and maintain HIPAA compliance
• Avoid accidental triggering of real-world workflows (billing, messaging, claims, automations)
• Allow teams to test aggressively without risk to live operations

Because of this architecture, automatic promotion from Staging to Production is intentionally not supported.

What Staging (Sandbox) Is For

A Healthie Staging account is designed to support:

• API development and integration testing
• Webhook validation
• Workflow prototyping
• Permission and role testing
• Provider and client experience simulations

What customers should test in Staging

Technical

• API requests and response handling
• Webhook event subscriptions and payloads
• Error handling and retry logic
• Permission-scoped API keys

Operational

• Intake and charting flows
• Scheduling and appointment logic
• Billing and insurance workflows (non-live)
• Automation and integration behavior

Security & Access

• Role-based permissions
• Integration user accounts with limited scopes

Why Data and Configuration Do Not Push to Production

Even though Staging and Production offer the same feature set, they are not mirrors of each other.

Key reasons data does not carry over:

1) Compliance & Security

• Production contains live PHI; Staging does not
• Mixing environments would introduce unacceptable risk

2) Infrastructure Isolation

• Separate databases, API keys, and webhook endpoints
• No shared identifiers across environments

3) Intentional Go-Live Control

• Forces teams to explicitly review and re-create configurations
• Reduces the risk of unintended automations, permissions, or integrations going live

Common misconception

“If it works in Staging, it should just be pushed to Production.”

Instead, the correct model is:

Build and validate in Staging → Recreate intentionally in Production

This mirrors best practices used by mature API platforms. 

API Keys and Webhooks: Environment-Specific by Design

API keys and webhooks are always environment-scoped.

• Sandbox API keys only work in Sandbox
• Production API keys only work in Production
• Webhooks must be created separately in each environment

Keys are also user-scoped, meaning:

• They inherit the permissions of the user who generated them
• They cannot be transferred between users

Best Practices for Transitioning to Production

1) Treat Staging as a rehearsal, not a template

Use Staging to:

• Prove workflows
• Validate integrations
• Confirm permissions and edge cases

But assume everything must be reconfigured intentionally in Production.

2) Document your Staging configuration

Before go-live, teams should document:

• API endpoints used
• Required permissions
• Webhook event types
• Automation logic
• Expected data flows

This makes Production setup faster and safer.

3) Generate new Production credentials

In Production:

• Create new API keys
• Create new webhooks
• Validate endpoints against live infrastructure

Never reuse Sandbox credentials.

4) Plan for controlled validation in Production

Once configured:

• Test with limited users or data
• Validate webhook delivery
• Confirm billing, messaging, and automation behavior

This step is critical before scaling usage.

5) Use Healthie’s Implementation & CS teams

Enterprise customers are supported by:

• Dedicated Implementation Managers
• Solutions Engineers (for API customers)
• Structured rollout trackers and milestones

This ensures Production launches are intentional, secure, and scalable.

When to Involve Healthie

Teams should reach out when:

• Planning complex API integrations
• Launching partner or marketplace integrations
• Managing multi-environment workflows
• Scaling from pilot to enterprise usage

For API and implementation questions:

• marketplace@gethealthie.com (partners, sandbox terms)
• hello@gethealthie.com (production access, implementation support)