Skip to main content

Supporting Multiple Partners Through One Integration

A guide for platforms setting up Honeybee on behalf of other partners​

Who this is for​

This guide is for organizations that integrate with Honeybee on behalf of one or more downstream partners, rather than integrating purely for their own use. If you're setting up eRx or fulfillment on behalf of a mutual partner (and especially if you expect to onboard more than one over time), this is the setup pattern to follow.

The core principle: each partner gets their own, completely separate setup​

Every partner you support needs its own, fully independent Honeybee setup, not a shared one. That means each partner gets:

  • Their own dashboard login
  • Their own unique webhook URL
  • Their own unique credentials (client ID and client secret)
  • Their own formulary
  • Their own dispensing fee structure

Nothing about one partner's setup is shared with or inherited by another, even though you're the one configuring and managing all of it. Think of it less like "one integration with several partners plugged in," and more like "several completely separate integrations that you happen to be the one setting up."

Why it has to work this way​

This isn't extra process for its own sake. Keeping each partner's setup fully separate is what makes a few important things possible:

  • Unique dispensing fees per partner. Each partner can have pricing that reflects their own agreement with Honeybee Health, rather than a blended rate.
  • Unique formularies per partner. One partner's available product catalog doesn't need to match another's.
  • Clean, direct billing and communication. Honeybee bills and interacts with each partner directly. Once a partner's setup is in place, your role is to relay information and make sure that partner is getting what they need, not to sit in the middle of billing or account-level decisions.

Keeping things separate from the start avoids muddying the waters later: mixed webhooks, mismatched formularies, or billing that's hard to untangle after the fact.

A note on logins: use alias emails​

Honeybee's login system ties one email address to one account across the platform. If your team is setting up multiple partner accounts, you won't be able to reuse the same email for each one as-is.

The easy fix: use alias emails for each partner setup. Most email providers support this automatically using a + after your username. For example:

bee+partnerA@yourdomain.com
bee+partnerB@yourdomain.com

Mail sent to either address still lands in your normal inbox, but Honeybee's system sees them as distinct logins, which lets your team create a separate dashboard account for each partner without needing a separate real mailbox for every one.

What this looks like day to day​

Once a partner's setup is complete, your day-to-day role is mostly about keeping the relay clean:

  • Confirming e-prescriptions are reaching Honeybee correctly for that specific partner
  • Making sure that partner's webhook events are flowing to the right destination
  • Flagging anything that looks off early, before it becomes a bigger mismatch

You're not merging partner data together on your end, and you shouldn't need to. Each partner's Honeybee setup already stands on its own.

Checklist: onboarding a new partner​

Use this each time you bring on a new partner under your integration:

  • Create a new dashboard login using an alias email (e.g. you+newpartner@yourdomain.com)
  • Generate a fresh, unique set of client credentials for that partner
  • Set up a unique webhook URL pointing to that partner's destination, not a shared one
  • Confirm the partner's formulary is configured correctly before go-live
  • Confirm dispensing fee structure is set for that partner specifically
  • Test end-to-end in Sandbox using that partner's own credentials before moving to production

Still have questions?​

If you're planning to support a new partner and aren't sure whether something should be shared or separate, check with your Honeybee implementation contact before building it out. It's much easier to set this up correctly the first time than to untangle a shared setup later.