Developers
One API surface, Builder, Functions, and sandbox. Prefer events. Ship in sandbox first.
Platform contract
The estate is the platform. API, Builder, Functions, and sandbox sit next to the products customers already run. Extensions should not invent a second login for the same human.
Prefer events on the estate bus over brittle poll jobs. Respect entitlements. Ship in sandbox first. Marketplace listings that break identity or data contracts do not pass review.
Full API reference lives with product docs and enterprise packages. Start at the API product page, then sandbox. Partners who ship extensions use the ISV path under the partner program.
When to use which surface
Use the API when systems outside CEDX need authoritative reads and writes under the same entitlements model. Use Builder when operators need low-code apps on CEDX data without a shadow CRM. Use Functions when logic should run next to the data without standing up a separate host you will forget to patch.
If your design requires nightly CSV reconciliation to keep two customer graphs aligned, stop and redesign. That seam is the problem the estate exists to remove.
Platform contract
The estate is the platform: API, Builder, Functions, and sandbox sit next to apps customers already run under one identity plane. Extensions must not invent a second login for the same human or a shadow customer graph that needs nightly reconciliation.
Prefer events on the estate bus over brittle poll jobs that fail silently and create support archaeology. Respect entitlements; never bypass identity for convenience; ship in sandbox first because production is not your lab.
Marketplace listings that break identity or data contracts fail review by design. If your design needs CSV reconciliation between two customer graphs, redesign — that seam is the problem the estate exists to remove.
Start at the API product page and sandbox; enterprise reference packages via contact; ISV partners list through the partner program security gate. Functions and Builder exist so you do not fork a shadow CRM that becomes tomorrow's reconciliation project.
Choosing a surface
Use the API for authoritative reads and writes under estate entitlements from systems outside CEDX. Use Builder for low-code apps on CEDX data when operators need tools without a custom host.
Use Functions for logic that should run next to the data without a server you will forget to patch. Use Marketplace when customers should install your extension on the same login after review.
Use sandbox to break safely and prove promotion paths; use events to react to the bus rather than polling for changes you will miss. Document entitlement assumptions so security review is not a surprise two weeks before go-live.
Reject designs that require prod-as-lab, entitlement bypass, or second-login UX for the same person. Those patterns reintroduce the stack sprawl customers hire CEDX to leave.
Partner builders
Apply as an ISV under the partner program, accept identity and data contracts, pass security review, prove in sandbox, then list. ISVs support first-line; CEDX supports platform contracts — write that into your customer SOWs.
Versioning and support expectations are part of listing discipline; abandoned extensions damage trust in the whole marketplace. Co-brand and naming must follow portal brand guidelines after approval.
Architecture labs for SIs cover identity, entitlements, data plane, and custom apps on Builder and API. Bring a real customer-shaped problem; lab time is not a tour of slides.
When platform behavior looks wrong, open Support with reproduction in sandbox and production where relevant. When commercial partner questions arise, use partner success queues by tier instead of severity-one product tickets.
Governance checklist
Second login for the same human: redesign. Shadow CRM or duplicate customer graph: redesign. Prod as lab without sandbox proof: comes back. Entitlement bypass: hard fail.
Nightly reconciliation as the primary integration style: redesign onto events and authoritative APIs. Hardcoded secrets in Functions: hard fail. Unscoped personal data exports: hard fail.
Listings that ignore shared-responsibility notes create customer risk CEDX will not underwrite. Read the security pack before you invent answers for a customer RFP.
Good extensions feel native on the estate: same login, clear entitlements, obvious support owner, sandbox-proven upgrade path. That bar is how Marketplace stays operator-grade instead of becoming a junk drawer.
Integration anti-patterns
Do not sync two customer graphs nightly and call it an integration strategy; pick an authoritative graph on the estate and integrate outward with entitlements. Nightly reconciliation is how Friday trust dies.
Do not create a second login for the same human to use your extension; if identity is hard, fix the design before you list. Second-login UX fails Marketplace review and fails operator adoption.
Do not use production as a lab; sandbox exists to absorb your mistakes without paging Support for self-inflicted outages. Promotion paths should be documented and boring.
Do not bypass entitlements for admin convenience; tomorrow that bypass is an audit finding and a breach story. Build with least privilege and test access reviews.
Do not ship Functions with hardcoded secrets or unscoped exports of personal data; those are hard fails in review and in production discipline. Use platform secret patterns and explicit scopes.
Event-first design
React to estate events when downstream systems need to know a customer, order, ticket, or entitlement changed. Polling creates lag, load, and missed updates that look like product bugs.
Design idempotent consumers; events will retry and duplicates will happen in real networks. Idempotency is not optional cleverness — it is production survival.
Document the event contracts you depend on and version your consumers when contracts evolve. Silent coupling is how partner extensions break on platform upgrades.
When you must poll, bound it, back off, and alert on drift rather than failing quietly. Quiet failure is worse than loud failure for operators.
Pair event design with entitlement checks on every write path; events are not a backdoor around access control. Security review will look for that mistake.
Builder and Functions guidance
Builder apps should use CEDX data models and entitlements so operators do not maintain a parallel mini-CRM. If Builder becomes a shadow system of record, you have recreated the problem.
Functions should be small, observable, and owned; orphan Functions are production landmines. Name owners in your internal runbook the same way you name product owners.
Prefer composition of estate products over reimplementing CRM, Desk, or Books features inside custom code. Custom code should fill gaps, not rewrite the suite.
Test multi-entity and multi-role scenarios in sandbox before customer UAT; identity bugs dominate late failures. Single-admin happy paths are not tests.
Observe and log with correlation IDs that Support can use; otherwise every incident becomes a guess. Debuggability is a product feature of your extension.
Listing and customer trust
A listing is a promise of support, versioning, and identity-safe behavior — not only a download button. Abandoned listings damage trust in every other extension.
Publish clear support contacts and severity expectations; customers should not open CEDX Support for ISV logic bugs first. CEDX will still own platform contracts; write the split into your customer terms.
Security notes on the listing should match what review approved; do not market capabilities you did not prove in sandbox. Overclaiming is how listings get pulled.
Upgrade paths should preserve entitlements and data; breaking changes need migration notes operators can follow. Surprise breaking changes become channel incidents.
When in doubt, redesign toward the estate rather than away from it; Marketplace exists to extend one login, not to reintroduce sprawl. That is the only listing strategy that ages well.
Surfaces
Practical detail for operators, partners, and builders evaluating the estate.
One surface for the estate.
Low-code apps on CEDX data.
Serverless next to your data.
Safe break before prod.
Principles
Practical detail for operators, partners, and builders evaluating the estate.
Never bypass identity.
React to the bus.
Prod is not your lab.
Surfaces in depth
Authoritative reads/writes under estate entitlements.
Low-code apps on CEDX data for operators.
Serverless logic next to the data plane.
Break safely; promote with review.
Distribute extensions after security review.
Prefer react-over-poll integration styles.
Governance
Same human, second identity — redesign.
Duplicate customer graph — redesign.
No sandbox proof — comes back.
Hard fail in security review.
Ship
Functions and Builder exist so you do not fork a shadow CRM.
FAQ
Straight answers before you book time or open a ticket.
Product pages and in-app docs; enterprise packages via contact.
Yes - Marketplace path after review.
Often for estate-adjacent logic. Keep external systems external when they own their own truth.
No. Builder runs on the same identity plane as the apps.
Open a live product, book an estate map, or join the partner program.
