Skip to main content

​
Changelog

​
Versioning

The Journeybee API is versioned via the URL path (/v1/). Breaking changes will only be introduced in new major versions. Non-breaking additions (new fields, new endpoints) may be added to the current version at any time.

​
v1.6.0

​
Commission rules (breaking change)

  • distributor removed from the POST /v1/commissions create enum — requests with partner_type: "distributor" now return 400 with error code distributor_commissions_unsupported, matching the app’s behaviour. Existing distributor rules are unaffected: they still list, read, update and delete.
  • This ships under a minor version as an exception to the versioning policy above, following the v1.4.0 precedent — the removed value was never usable in the app.

​
v1.5.0

​
Validated custom fields

  • New field types — custom fields now support email, website, phone, textarea (Long text), and checkbox, in addition to the existing types.
  • Canonical values — text-like fields write { "text": ... } (textarea still reads legacy { "textarea": ... } values), while boolean and checkbox require actual boolean values under { "boolean": ... }. Blank values are stored using the field type’s canonical clear (null, or [] for multi_select).
  • Validation and normalization — email, website, phone, and long-text values are validated on every write. Website values accept bare domains and are stored as canonical HTTP(S) URLs; phone values are stored in E.164 form. Whitespace-only text-like values do not satisfy required fields, while number 0 and boolean false remain valid answers. A required checkbox must be checked.
  • Field guidance — every custom field type can include help text and an HTTP(S) link. Public forms render the link and description with the field control, and Slack lead submission modals show the same guidance.
  • Embedded form prefill — embedded lead forms can prefill text, long text, email, website, phone, and number custom fields by field UUID.

​
v1.4.0

​
Custom field enforcement (behavior change)

  • Server-side enforcement on every custom field write — creating or updating a lead, deal, or partner with custom field values (inline, via POST/PATCH/DELETE /v1/custom-field-values, or via the per-entity custom-field endpoints) is now validated against each field’s required flag, its partner_type scope, and any active custom field rules (visibility, locking, auto-population). Previously these writes could silently persist values that violated required/rule/scope constraints. A violation now returns 400 validation_error with a details array — see Custom field validation.
  • DELETE is treated as a blanking submission — deleting a visible required value returns required_cannot_blank; deleting a value locked by an active rule returns locked_by_rule.
  • This is a deliberate behavior change for existing admin-API consumers (the API enforces immediately rather than rolling out gradually) — see the custom field validation guide for the full reason code reference.

​
Partner field requirements (new endpoints)

  • GET /v1/partner/{partnershipId}/leads/requirements and GET /v1/partner/{partnershipId}/deals/requirements — new read-only endpoints that return the custom fields (with their required flag) and active rules a partner’s lead/deal submission must satisfy, computed from the exact same logic the write-side validator enforces. See Field requirements in the Partner API guide.
  • createPartnerLead, updatePartnerLead, createPartnerDeal, and updatePartnerDeal now document calling the matching requirements endpoint first, and that validation failures return per-field details with machine-readable reason codes.

​
Lead creation (breaking change)

  • partnership_uuid is now required on POST /v1/leads — leads always belong to a partnership; campaign leads are created through campaign surfaces (portal campaign forms / public form submissions), not this endpoint.

​
v1.3.0

​
Audit Log

  • Audit Log — GET /v1/audit-log returns a unified, company-scoped activity feed across leads, deals and partnerships. Each entry carries the entity, action (created / updated / deleted / archived / restored), a rendered actor label, and a changes array describing what changed.
  • Expanded field coverage — audit entries now track many more fields per entity:
    • Partners — name, email, phone, website, description, partner type, offline flag, accepted/invited dates, country, currency (in addition to tier, category, stage, archive state).
    • Deals — currency and expiration date (in addition to label, value, commission, stage).
    • Leads — rejected reason, direction, campaign and distributor (in addition to contact fields and status).
  • Human-readable values — foreign-key fields resolve to labels rather than ids (stage, tier, category, country, currency, campaign, distributor), deal amounts are formatted in the deal’s currency, and create entries are attributed to the record’s creator.

​
v1.2.0

​
Resources & LMS

  • Resources — Full CRUD with content blocks (text, image, video, document, embed, quiz, and more), tags, categories, and folder organization
  • Certifications — Full CRUD with curriculum management (ordered resources with prerequisites), enrollment tracking, categories, and folders
  • Folders — CRUD for organizing resources and certifications into hierarchical folders

​
Rooms

  • Rooms — Full CRUD for partner portal pages with 16 room types and 14 block types (text, video, action bars, banners, goals, pricing calculators, etc.)
  • Room access control — Manage room visibility via tiers, categories, stages, tags, and direct partnership associations

​
Webhooks

  • Webhook event schemas — Full typed payload documentation for all 16 webhook events (leads, deals, partners, messages) in the API Reference

​
Improvements

  • JSONB fields fully typed — Commission calculations, pricing calculator configs, resource block content, room block settings, and custom field values now show complete structures in the API docs
  • UUID validation — All UUID parameters now validate format (previously accepted any string)
  • Asset company scoping — Asset references now verify company ownership

​
v1.1.0

​
Developer Tools

  • TypeScript SDK — @journeybee/sdk with typed functions for every endpoint. See the SDK guide.
  • MCP Server — Connect Claude and other AI assistants to Journeybee. See the MCP guide.
  • operationId on all endpoints — Every endpoint now has a stable operationId (e.g., listLeads, createPartner) for SDK method names and MCP tool names.

​
New Endpoints

  • Leads — Full CRUD with sub-resources: tags, assigned users, contacts, custom fields, notes, attributions, distributors, products, quotes, tasks
  • Deals — Full CRUD with sub-resources: tags, notes, products, payments, custom fields, commission, tasks
  • Tasks — Full CRUD with assigned users
  • Commissions — Full CRUD with tier/category/partnership scoping
  • Contacts — List and get across partnerships
  • Products — Full CRUD
  • Pricing Calculators — Full CRUD with fields, products, and formulas
  • Attributions — Full CRUD
  • Currencies — List
  • Users — List company team members

​
v1.0.0

Initial release

​
Endpoints

  • Partners — Full CRUD with sub-resources: tags, assigned users, domains, custom fields, contacts, notes, resellers
  • Partner Stages — List, create, update, delete
  • Deal Stages — List, create, update, delete
  • Tiers — List, create, update, delete
  • Categories — List, create, update, delete
  • Tags — List, create, update, delete
  • Custom Fields — List, create, update, delete with option management
  • Custom Field Values — List, create, update, delete

​
Authentication

  • Bearer token and Api-Key authentication
  • Read/write permission model
  • Rate limiting (100 requests/minute)