Developed Integrations
Developed Integrations is for building an integration that other Journeybee customers can install. If you are a software vendor, or a partner with your own systems, this is where you register your integration, subscribe it to webhook events, and publish it so it appears in the integrations directory.
This is not the page for connecting Journeybee to a tool you already use. For that, see Integrations.
Where to find it: Go to Settings, then Developed Integrations.
Who can use this: Admins, and only when the API & MCP module is enabled. The page does not appear otherwise. Contact Journeybee support to have it turned on.
How it fits together
An integration you build here has three moving parts:
Outbound: Journeybee sends you webhook events when things change in your customer's account.
Inbound: your system calls the Journeybee public API to read or write data.
The card: how your integration presents itself to a customer deciding whether to install it.
Each customer installs your integration from their own Integrations page and confirms the access it asks for.
Create an integration
Click Create on the Developed Integrations page, then open it to configure it. A new integration starts Unpublished, so it is not visible to customers while you build it.
Information card
This is what a customer sees when browsing integrations. Upload your Company Logo and, optionally, link a Help article so customers have somewhere to read about setup.
Write the card for someone who has never heard of you. "Syncs deals to Acme Billing so invoices are raised automatically when a deal is won" tells them more than your product name does.
Details
Label: the integration's name.
Help article: a URL to your own documentation.
Integration details: the longer description of what it does.
Import data
Optional. Turning on Enable import data gives your integration a dedicated import experience inside Journeybee, driven by your own endpoints.
Preview URL: called to show the customer what would be imported.
Execute URL: called to run the import. Leave it blank and the configuration submit URL is used instead.
The section shows Configured or Incomplete so you can tell at a glance whether the endpoints are set.
Webhook subscriptions
Subscribe to the events you care about and give each one a webhook URL. Journeybee then posts to that URL when the event happens in a customer's account.
Available events:
Leads
Lead Created, Lead Updated, Lead Deleted
Lead Note Created, Lead Note Updated, Lead Note Deleted
Deals
Deal Created, Deal Updated, Deal Deleted
Partners
Partner Created, Partner Updated
Partner Contact Created, Partner Contact Updated
Payments
Payment Processing, Payment Completed, Payment Failed
MDF
MDF Payout Completed, MDF Payout Failed
Only subscribe to what you will act on. Every event you take is traffic you have to receive, verify and discard.
If the event you need is not listed, email engineering@journeybee.io.
Public API requirements
Declare whether your integration needs read access, write access, or both, to the Journeybee public API.
This is not just documentation. The customer confirms these permissions when they set your integration up, so ask for what you actually need. An integration that only pushes data into a reporting tool should not be asking for write access.
See API Keys for how customers authenticate against the public API.
Integration secret token
Your integration has a secret token, used to encode and decode the JWT bearer token attached to every webhook event Journeybee sends you.
Verify it on every incoming webhook. An unverified webhook endpoint accepts anything anybody posts at it, and a payload full of your customer's partner data is worth forging.
Keep the token server-side and never in client code. If you need it rotated, get in touch with Journeybee.
The verification details are in the developer documentation: docs.journeybee.io/guides/webhooks.
Publishing
An integration is either Published or Unpublished. Unpublished is the working state: configure it, point your webhooks at a test endpoint, and confirm you receive and verify events end to end before you publish.
Publishing makes it available for customers to install.
Removing an integration
Remove integration deletes it. Customers who have it installed lose it, so unpublish first and tell them before you delete.
For your developers
The full technical reference lives in the Journeybee developer documentation:
Webhooks: payload shapes, signature verification, retries.
Authentication: calling the public API.
SDK: the TypeScript client.
Idempotency and Errors.
Troubleshooting
Developed Integrations is not in my settings
It needs the API & MCP module and the Admin role. Contact Journeybee support to have the module enabled.
We are not receiving webhook events
Check the integration is Published and installed by the customer whose data you expect, that the event is actually subscribed, and that the webhook URL is publicly reachable and answers quickly.
The JWT will not verify
Confirm you are using the integration secret token from this page and not an API key. They are different credentials for different directions of traffic.
The import section says Incomplete
The Preview URL is missing. The Execute URL is optional and falls back to your configuration submit URL, but Preview is not.
A customer says the integration asks for too much access
They are reading the Public API Requirements you declared. Narrow it to read-only if you do not write back.
Good to know
Build unpublished, publish once. An unpublished integration is invisible to customers, so you can iterate freely.
Verify every webhook. It is the one step people skip and the one that matters.
Ask for the least API access your integration can work with. Customers see the request and act on it.
Point the Help article field at your own documentation. It is often the deciding factor when a customer is choosing whether to install.
Related articles
Integrations: connecting tools you already use.
API Keys: authenticating against the public API.
Zapier: automating Journeybee without writing an integration.