Embed governedZoikoTax capabilitieswithout losing tenantaccountability.
Use approved partner provisioning and embedded integration patterns toconnect organizations, activate permitted capabilities and preserve clearattribution, isolation and evidence.
This page explains public partner/embedded architecture. It does not grant reseller, white-label, branding, pricing, distribution or contractual rights. Thoserequire approved commercial/legal sources.
What does OEM /Embedded mean?
Approved partners may connect ZoikoTax capabilities to a wider platform or service whileeach organization’s business context, capability scope and evidence remain explicit.
Technical embedding, partner identity approval, capability entitlement and production activation are separatedecisions. Commercial rights are separately governed; navigation or test access grants none of them.
One embedded proposition. Explicit responsibilities.
Embedding connects responsibilities; it does not merge their authority.
Text equivalent: the partner owns its wider experience and approved integration; the organization remains the authorized business context; ZoikoTax provides supported fiscal controlsand evidence within the approved scope.
Confirm the exact organization separation, access and external-system contracts. The diagram does not define authentication, delegation, tenant hierarchyor cross-tenant visibility.
Provisioning is a sequence of governed decisions.
Follow the approved lifecycle without treating setup as an entitlement or activation shortcut.
Authorization is not a public signup or a capability grant.
Exact objects and association mechanics follow approved source contracts.
Use source-defined configuration; no fields or schemas are implied here.
Creating a context does not grant permission; entitlement has its own authority.
Validation gates are independent and do not automatically pass.
Test permission and validation do not establish production entitlement.
The governed operating model defines responsibility; no SLA is promised.
Data, historical access and lifecycle handling remain policy-controlled.
Read this sequence in order: registration / authorization ➔ organization creation / association ➔ configuration ➔ entitlement ➔ validation ➔ activation ➔ operate ➔ offboard. Each boundary requires its approved source; no instant self-service activation is implied.
Keep the organization visible at the point of consequence.
Partner identity and organization identity are separate. Attribution provides accountability, not unrestricted cross-tenant visibility.
Illustrative categories only. No identifier, key, APIfield, delegation model or fixed tenancyrelationship is specified.
Keep organization context and capability scope visible near consequential actions. Confirm the identity, authentication and authorization contracts in the APIReference; never infer tenant hierarchy, RBAC or cross-tenant access from these conceptual categories.
A provisioned context is not permission to run.
Approve the exact capability, Coverage and environment independently before production activation.
Only the approved partner-eligible catalog can establish eligibility. Exact states, effective changes andrevocation behavior follow formally governed sources. Public navigation is not a catalog grant anddoes not make capabilities available automatically to every partner or tenant.
Text equivalent: provisioned context ➔ entitlement approved ➔ Coverage / environment / security validated ➔ production activation approval. Navigation,partner context and sandbox access do not bypass any gate.
Connect the experience. Preserve the boundary.
API-led embedding can place an approved integration within a partner's own UI. It does not imply a white-labeled ZoikoTax application.
Own experience, approved API use, explicitorganization context.
Only the approved scope and environment.
Text equivalent: the partner-owned experience connects through an approved interface to supported ZoikoTax capabilities. Organization, permission andevidence boundaries remain explicit on both sides.
Technical embedding is not a commercial permission.
Keep the integration pattern separate from the rights to market, brand, distribute or sell it.
Partner-owned UI, organization context, approved APIs, permittedcapabilities and evidence boundaries describe technical architecture.
Entitlement and activation are governed decisions. Neither one definesbranding or distribution rights.
ZoikoTax marks and attribution follow approved brand and contractsources. White-label rights are conditional, never implied; no "Poweredby" rule is established here.
Resale, distribution, pricing, revenue share and partner tiers requireseparate approval. Technical documentation does not offer terms.
Begin with technical diligence. Use Book a Demo for contextual commercial qualification; approved commercial, legal and brand owners determine theapplicable rights.
Attribute activity. Do not infer economics.
Usage can support operational accountability when its organization, capability and evidence context are preserved.
Text equivalent: approved activity ➔ correct organization ➔ capability ➔ source-defined period ➔ evidence / operations. These categories are not a usage schema, report, billing cycleor dashboard.
Usage does not establish allowances, revenue share, charges, invoice frequency or commercial economics. Authenticated reporting is separate from thispublic architecture page; no actual counts, periods or usage records are shown.
State changes need authority, not assumptions.
Illustrative state meanings — production taxonomy source-controlled
Every transition depends on the actual policy, contract and operating model. The states below are explanatory categories, not a fixed progression, eventcontract or live organization status.
If the governing state or procedure is missing, do not infer activation, restoration or offboarding behavior. Confirm the approved source. No trigger, noticeperiod, retention duration, restoration promise or right to service is established here; there are no live suspend or deprovision controls.
Route the issue to its accountable owner.
Use the approved support model and authoritative sources. A developer route cannot grant commercial or production rights.
Partner, tenant and ZoikoTax responsibilities stay distinct. Confirm escalation ownership before activation; this public page supplies route-first guidance, nota new support contact, SLA or delegation model.
Keep the decision trail with the organization.
Traceability supports accountability. It is not an unsupported assurance or certification claim.
Connect provisioning, entitlement and activationto their governing sources. Preserve approvedconfiguration and usage references soconsequential actions can be reviewed in context.
Actor attribution is included only where thesupported model permits it. It does not establishdelegation, impersonation or cross-tenant access.
Evidence & ReplayText equivalent: organization context, entitlement source / effective scope, activation readiness / Coverage, supported actor attribution, configurationversion, approved usage reference and historical review form a conceptual evidence trail. No actual identifiers, timestamps, audit records or certificates areshown.
Make the boundary explicit. Minimize what crosses it.
Confirm the exact security and privacy contract rather than inferring a universal isolation or permission implementation.
Use categorical page and route context only. Never expose partner, tenant or customer identifiers, entitlement details, secrets, usage values, commercialterms or raw free-text in public analytics.
Test the supported scope. Approve production separately.
A sandbox is a separately enabled environment, not a shortcut to production privilege.
Use Developer Overview and the API Reference for the exactauthentication and API model. Test provisioning only where the sandboxactually supports it.
Use synthetic organization-scope validation. Test-vs-productionentitlement stays separate; review exact Coverage, approved securityand onboarding requirements.
Use documented lifecycle events only if they exist in approved sources.Webhooks & Events is context, not a promise of provisioning events.
Sandbox permissions do not grant production entitlement, and a successful test does not approve activation. Confirm every applicable source and ownerbefore progressing.
Move forward only when the next boundary is clear.
A docs-first journey with safe handling for missing sources, unknown entitlement and unavailable routes.
Focus is visible without relying on motion or hover.
Open API ReferenceOrganization context, entitlement, Coverage,environment and activation approval are distinct.No grant is implied by this explanatorydisclosure.
These are conceptual public explanations, not actual tenant states or operating controls. Meaning is written in text rather than color alone; diagrams includetext equivalents and no essential information depends on hover or motion.
Direct answers. No implied rights.
Public architecture guidance; exact technical, operational and commercial mechanics remain governed.
It describes approved partner provisioning and embedded capability patterns within a wider platform or service. Organization boundaries, capability scope, attribution and evidence remain explicit; technical embedding does not grant commercial rights.
Confirm the approved partner identity and the actual organization model first. Exact creation, association and configuration mechanics follow platform and API source contracts. Provisioning does not itself create entitlement or approve production activation.
No. White-label, branding, attribution, resale and distribution permissions require approved commercial, legal and brand sources. Neither an API integration nor a partner context implies those rights.
Verify the partner-eligible capability source, commercial / product grant, exact Coverage, environment and security readiness, then obtain controlled production activation approval. Navigation and test permission do not establish production entitlement.
Use the supported organization context and source-defined capability, period and evidence references. Exact reporting mechanics remain governed and authenticated reporting is separate. Attribution does not establish charges, pricing, allowances or revenue share.
Follow the approved lifecycle, restriction and data-handling sources with the accountable operational owner. Do not infer triggers, notice, restoration, retention or a right to continued service from this public page.
Start with the sources that govern your integration.
Technical diligence first. Review evidence and readiness next; commercial qualification remains a separate conversation.
Developer Overview · /developers/
Webhooks & Events · /developers/webhooks-events/
P3 · Book a Demo · /demo/
Plan the integration. Preserve accountability.
Explore the technical guides, confirm the exact scope and bring commercial questions to approvedqualification. No signup or self-service grant is implied.
OEM / Embedded · /developers/integrations/oem-embedded/