Build with ZoikoTax through governed integration paths.
Use public APIs, asynchronous patterns, events, SDKs and integration guidance to connect ZoikoTax to telecom financial architecture while preserving fiscal authority, evidence, security and capability-availability boundaries.
Public documentation explains approved concepts and routes. Production credentials, entitlement and live market availability remain separately governed.
What is theDevelopers area?
The Developers area is the public entry point for integration concepts, contract documentation and approved implementation patterns. It helps engineering teams choose the right API, SDK, event, bulk, sandbox or integration path. It is not a substitute for contractual entitlement, production credentials, current Coverage state or private implementation documentation.
A route through the decisions that matter.
Pick the task you need to complete—not a product owner you have to guess. Follow the path from architectural context to qualified implementation scope.
- 01
Choose integration context
Locate the family closest to your architecture.
- 02
Review core contract model
Separate evaluation, authority and evidence.
- 03
Choose implementation surface
API, SDK, events or asynchronous bulk.
- 04
Use Guide / non-production Sandbox
Confirm testing access and environment scope.
- 05
Check Changelog
Review version and compatibility guidance.
- 06
Verify Trust / Coverage independently
Security evidence and market state are separate.
- 07
Engage qualified scope
Discuss contractual implementation boundaries.
Authentication and environment selection belong in getting started.
Exact mechanisms, environment URLs and access requirements remain source-controlled. Use canonical documentation and controlled onboarding; this overview does not issue credentials or establish production access.
Choose the surface. Read its contract.
Four canonical resources, each with a distinct implementation purpose. This overview routes you to the detail; it does not define the production API.
API Reference
Versioned endpoints, schemas, errors and contract details. Use the canonical REST reference for exact implementation syntax.
SDKs
Supported client libraries and versions. SDK behavior aligns with canonical contracts where supported; no language or package is implied here.
Webhooks & Events
Event-driven integration contracts and delivery semantics. Signing is conceptual here; exact mechanisms belong to the source contract.
Bulk & Batch
High-volume asynchronous / batch integration patterns. Review canonical processing contracts rather than infer limits or queue behavior.
Documentation is not an availability badge. Supported surfaces, access and capability state must be verified from their governed sources.
Move from understanding to implementation.
Integration Guides
Architecture patterns and approved implementation guidance. Follow canonical documentation for exact syntax and source-bound implementation detail.
Sandbox
Non-production testing for an approved implementation context. Access remains separately governed; a sandbox is not production parity, entitlement or certification.
API Changelog
Version and compatibility changes—not marketing news. Review the canonical change record; this overview makes no current-release or support-date claim.
Fit the architecture you already operate.
Choose your integration context, then review what ZoikoTax connects—and what remains owned by the surrounding systems.
Billing & BSS
Quote, commit, invoice and transaction integration within telecom financial workflows.
Not a full BSS, OSS or rating replacement.
ERP & General Ledger
Controlled journals, an accounting bridge and reconciliation across retained enterprise systems.
The general ledger remains the accounting system of record—not replaced.
Existing Tax Engines
Federated, Shadow and migration adapter patterns for coexistence with an incumbent.
Comparison does not automatically establish legal or authoritative truth.
E-Invoicing Networks
Approved network and authority adapter patterns for e-invoicing workflows.
No universal or direct regulator, clearance or certification support is implied.
Data & Enterprise Systems
CPQ, CRM, product-catalog and approved data-platform architecture patterns.
Not universal vendor certification or support. Route subject to governed publication.
OEM / Embedded
Partner provisioning and embedded capability with retained tenant and legal-entity attribution.
Isolation and commercial permissions are separately governed—not unrestricted resale.
Connect systems. Retain their owners.
Illustrative conceptual architectureSource systems
Billing • enterprise • incumbent
Operational owners retained
ZoikoTax fiscal controls
Approved state • evidence • authority
Governed fiscal boundary
Downstream systems
Accounting • networks • partners
Acceptance owners retained
Evaluation is not an authoritative write.
Keep provisional work, governed commits and external acceptance distinct. Preserve evidence context and deterministic authority across every integration surface.
Quote / preview
A non-committing evaluation is distinct from a fiscal commit. Preview results do not create an authoritative write or establish external acceptance.
Evaluate → review → retain context
Commit / write
An authoritative write is permitted only through approved state and canonical contract semantics. Idempotency and evidence belong to that governed contract.
Approved state → authoritative action → evidence
Versioned contracts
Versioned REST contracts define implementation behavior. Follow the Changelog for source-controlled compatibility guidance.
Asynchronous bulk
Bulk work is asynchronous. Limits, queue behavior, polling and processing SLAs are not established by this overview.
Events & webhooks
Notifications are not legal or external acceptance. Signing, delivery, retry and ordering semantics are source-bound.
Correlation & problems
Preserve correlation and problem-detail context for diagnosis and evidence. No specific field names or RFC contract is defined here.
Shadow observes and compares without affecting authoritative outcomes until governed review and cutover. Comparison is evidence for a decision—not automatic legal truth, fiscal authority or an AI-authorized outcome.
Orientation here. Exact truth at the source.
Public
Integration concepts, canonical documentation routes and conceptual architecture. Enough context to choose the right path without a lead gate.
Orientation • resource purposes • system boundaries
Source-controlled
Exact API, SDK, event, environment, authentication and access contracts. Use canonical sources and controlled implementation documentation as applicable.
Contract syntax • access scope • private implementation
Public documentation does not replace private implementation material. Currentness and contract metadata should appear only when verified—not as an inferred “latest” label.
Ask the right question. Check the right source.
Contract detail, security evidence, market capability and commercial permission are independent domains. None can be inferred from the others.
Is the capability live?
Check current capability-specific Coverage. A documented integration concept is not evidence of live market availability.
Where is security truth?
Use Trust Security for the security evidence domain. This overview does not establish certifications or control guarantees.
Privacy or residency?
Use Trust and Privacy guidance, with controlled disclosure where needed. Global scope does not mean universal residency.
How do I get access?
Start with API documentation. Production access is controlled onboarding; discuss contractual scope in a qualified demo.
What has changed?
Use the API Changelog for version and compatibility guidance. Do not infer currentness from this overview.
Where can I test?
Read Sandbox guidance for non-production testing. Testing access is separately governed and does not establish production rights.
A useful path for every entry point.
Billing engineer
Billing & BSS → API Reference → Guide / Sandbox → Changelog → Coverage → scope Demo
Begin with the financial workflow, review the contract, test within approved non-production access and qualify capability before implementation.
Enterprise architect
Incumbent / ERP path → ownership boundary → Integration Guide → Trust / Coverage
Plan coexistence and reconciliation around retained systems of record. Verify security, privacy and market state independently.
Resource registry unavailable
Hero → static canonical route cards → source documentation
Core orientation remains useful without dynamic inventory. Unknown snippets are safely suppressed; no contract or capability claim is invented.
Keep the path useful. Never fill gaps with claims.
Conceptual state patterns—not actual outages or live service status. Critical copy and navigation remain readable while optional detail is absent.
API Reference
Canonical contract documentation remains the route forward.
Loading enrichment does not block the canonical route. Unverified metadata and examples are omitted.
- Canonical resourcesNormal
- Core route cards and their purposes stay visible.
- Dynamic content loadingNon-blocking
- Load dynamic detail only; no spinner blocks the page.
- Version metadata unavailableOmit
- Do not infer “latest” or fabricate currentness.
- Example unavailableOmit
- No substituted endpoint, schema or code.
- Sandbox restrictedAccess governed
- A neutral access state—not an outage claim.
- Changelog unavailableStatic route retained
- Keep the canonical route; do not show stale news.
- Child destination unpublishedNo dead link
- Data & Enterprise Systems remains purpose-only.
- Coverage unavailableNo inference
- Documentation does not establish market capability.
- No JavaScriptLinear core retained
- Identity, direct answer and core routes stay readable.
- Slow networkProgressive shell
- Prioritize critical copy and navigation over enrichment.
Explain the architecture.Protect the detail.
Keep sensitive data out
Do not put secrets, credentials, private authority, tenant, customer, subscriber, tax or ledger payloads in public examples, forms or analytics. Analytics should use categorical route and placement—not raw code, free text, payloads or uncontrolled URLs.
Keep mechanisms source-bound
Do not infer authentication or signing. Retain downstream OEM, tenant and legal-entity separation. Use Trust for privacy and residency; do not assert performance or certification without evidence.
Keep assistance bounded
AI may explain approved concepts. It must not invent technical contracts, law or fiscal authority. Canonical engineering, security, entitlement, release and Coverage sources take precedence over editorial content.
Direct answers. No inferred contracts.
The essential decisions, with source-safe answers visible on the page.
- How do I integrate ZoikoTax?
- Choose the integration family that fits your architecture, review the canonical contract, then use approved guidance and non-production testing. Verify Coverage and implementation scope separately.
- Where are the API docs?
- API Reference at /developers/api/ is the canonical route for versioned endpoint, schema, error and contract documentation. This overview is not the production API contract.
- Which integration family should I choose?
- Start with Billing & BSS, ERP & General Ledger, Existing Tax Engines, E-Invoicing Networks, Data & Enterprise Systems or OEM / Embedded. Match the retained system owner and review the explicit boundary.
- When should I use APIs, SDKs, events or bulk?
- Use the API contract as the foundation. Review SDKs for supported client libraries aligned with it, events for notification contracts and Bulk & Batch for asynchronous patterns. Exact supported behavior belongs to each canonical source.
- Where are authentication and environment details?
- They are getting-started concerns defined by source-controlled documentation and controlled onboarding. Do not infer protocols, credentials, environment URLs or production access from this overview.
- Can I test in a Sandbox?
- Read /developers/sandbox/ for non-production testing guidance. Access is separately governed; sandbox use does not establish production parity, entitlement or certification.
- Does documentation mean a capability is live?
- No. Check /coverage/ for current capability-specific market state. Documentation, implementation access, Trust evidence and commercial entitlement are separate.
- How do I track version changes?
- Review /developers/changelog/ for canonical version and compatibility guidance. Do not infer a latest version, support window or deprecation date from this page.
- Can ZoikoTax coexist with an incumbent tax engine?
- Review Existing Tax Engines for federated, Shadow and migration adapter concepts. Shadow comparison remains non-impacting and non-authoritative until governed review and cutover; it is not automatic legal truth.
- Where is security, privacy and residency truth?
- Use /trust/, /trust/security/ and /trust/privacy/, with controlled disclosure as appropriate. Global platform orientation does not establish universal residency or certify a specific deployment.
Build from the canonical contract.
Read the public documentation, choose an integration pattern and verify Coverage. Then discuss contractual implementation scope—not instant activation.
Public technical content is not lead-gated. Production credentials and entitlement remain separately governed.