Integrate with ZoikoTax through governed events and webhook contracts.
Use public event-driven integration guidance to understand notification contracts, webhook verification, delivery semantics and version/change boundaries without treating illustrative content as a production event catalog.
Exact event names, payloads, signing mechanics, retries, ordering and delivery guarantees are governed contract data.
Contractdeliveryverificationconsumer
CONCEPTUAL · NOT A DELIVERY GUARANTEEGoverned contract
Discover controlled identity, version and purpose.
Delivery
Interpret attempts and receipt under the contract.
Verification
Apply the protected, governed procedure.
Consumer
Handle replay safely; check API authority.
Discover the contract, interpret delivery, verify the notification, then resolve identity and replay before consumer action. Receipt, attempt and acknowledgement do not establish final business or fiscal success.
A notification contract. Not final fiscal truth.
This page helps teams discover governed event guidance, understand verification and delivery boundaries, and plan replay-safe consumers. Resolve current authoritative state through the API when the contract requires it; use the Changelog for change boundaries. No production event inventory or exact delivery mechanics are supplied here.
Events notify. APIs resolve. Bulk executes.
Select the integration surface by its role—not by assuming equivalent authority or delivery behavior.
Understand a signal
A contract-defined notification may inform a consumer or a workflow. Its business meaning and authority are source-dependent.
Receive a contract
A transport mechanism for notifications. Delivery, verification and acknowledgement semantics come from the governed contract.
Resolve or act
Use documented read/write operations for authoritative current state or a permitted action. Notification receipt is not that action.
Handle grouped work
Consult Bulk & Batch for execution contracts. A notification does not establish completion of a bulk operation.
Coverage is not entitlement
Coverage describes capability readiness. Entitlement and environment enablement are separate checks; neither is implied by this guidance.
Discover only what is governed and published.
A registry entry must come from a controlled source. This view has no supplied production event records; examples elsewhere on the page are not catalogue entries.
Version, lifecycle and family facets appear only when governed records provide them. No default version or invented facet values are shown.
No governed public event registry entries supplied in this view
There is no event inventory to browse here. Do not infer that an event exists, is enabled or is supported. Continue with the API Reference, integration guidance and published change information.
No matching governed entries
Clear the search with Reset and review the available source. No match must not become a guessed event name or version.
Registry source unavailable
Keep the core guidance readable and open related docs. Do not display cached or missing records as a current, verified catalogue.
Identity, purpose and authority stay separate.
Illustrative anatomy only—not a selected published event. Every value and semantic boundary must be resolved from a governed source before implementation.
Illustrative example — not a production schema
Controlled identity: <event-id> · Controlled version: <version>. These are placeholders, not event names or version selections.
- Purpose
- Why the notification exists, which context it describes and which consumers may rely on it. No purpose or production scope is supplied here.
- Informational semantics
- Whether the event is informational only. Do not infer business or fiscal authority from its identity or arrival.
- Workflow semantics
- Whether it permits a workflow step, and which preconditions, approvals or current-state checks apply. This is source-dependent.
- Follow-up API authority
- Whether a documented API read or write is required. The API/current-state contract remains authoritative where specified.
- Payload schema
- Read the controlled schema, compatibility rules and data-minimization boundary. A placeholder is not an implementation schema.
Define the boundary before the receiver.
These are planning concepts—not a self-service subscription flow, activation mechanism or promise of availability.
Entitled context
Confirm the permitted integration context independently of Coverage. Access is not established by reading public documentation.
Receiver destination
Establish the permitted receiving destination under the controlled provisioning process. No callback URL or endpoint is supplied.
Scoped events
Select only source-defined event scope if it is published and permitted. Do not infer a catalogue or universal subscription.
Createchangepauseretire
Conceptual lifecycle: establish an authorized configuration, govern scope changes, pause where the controlled process permits it, then retire under that process. These labels do not imply available endpoints, immediate effect, retained history or a working subscription here.
Provisioning mechanics remain source-controlled
Use the published integration guidance and authorized process for exact setup. Environment, entitlement, Coverage and security approval must not be collapsed into a single availability claim.
Verify before trusting. Resolve before acting.
The sequence is conceptual. Exact signing and verification mechanics belong to the governed contract, not this illustration.
- 01
Receive
Treat incoming material as untrusted until the governed checks complete.
- 02
Preserve required raw context
Keep only the context required by the protected procedure. Do not reshape it before the required verification step.
- 03
Apply the governed protected procedure
Use the exact controlled verification instructions. No algorithm, header, credential or validation window is specified here.
- 04
Reject or quarantine unverifiable material
An unverifiable notification must not enter trusted processing. Never silently accept on a best-effort basis.
- 05
Resolve identity, version and correlation
Use source-controlled meanings. An unknown identity or version requires investigation rather than invented interpretation.
- 06
Check replay safety and authority
Prevent blind repeated effects. Resolve current authoritative API state where needed before consumer action.
- 07
Keep minimal evidence
Record permitted verification and handling evidence with safe correlation. Redact secrets and sensitive payload content.
Secrets are not diagnostic evidence
Do not publish credentials, verification material, raw payloads or private identifiers. Use redacted, minimal evidence through an authorized support process. Restricted verification instructions remain protected; public guidance is not a substitute.
An attempt is not a business outcome.
Illustrative text state guide—not live telemetry or an asserted ZoikoTax state machine. Interpret a state only when its meaning is defined by the governed source.
- Transport attempt ≠ receipt
- Receipt ≠ trusted verification
- Acknowledgement ≠ final success
- Prepared / queued
- May describe work prepared for transport. It is not evidence that the receiver was reached or that a consumer acted.
- Sent / attempted
- Describes a transport attempt only. It does not establish receipt, verification or consumer success.
- Acknowledged / accepted
- A source-defined acknowledgement may describe receipt or acceptance. It must not be read as final business or fiscal success.
- Delayed
- Timing or progress is unresolved under the controlled semantics. Do not show an invented ETA or assumed retry schedule.
- Failed
- Use the source-defined failure meaning to distinguish transport from recipient processing. Do not infer a final fiscal outcome.
- Duplicate / replayed
- Previously seen or replayed material requires identity and correlation checks. Arrival does not justify repeating side effects.
- Unknown / status unavailable
- No trustworthy current status is available. Keep uncertainty explicit; never substitute stale success.
- Deprecated / withdrawn
- Show only if a governed source supplies this lifecycle status. Consult the published change boundary before relying on it.
No delivery guarantee is inferred
This page supplies no ETA, order, retry count or timing, retention, durability, SLA, latency or exactly-once guarantee. Read only the mechanics that the controlled contract actually publishes.
Keep identity stable in meaning—not guessed in shape.
Separate the notification wrapper from the business payload. Names, schema versions and compatibility rules must come from the controlled contract.
Illustrative example — not a production schema
- Identity
- <event-id>
- Schema version
- <version>
- Correlation
- <correlation-reference>
- Payload
- <payload>
Text equivalent: a governed identity and schema version identify the contract; correlation connects permitted evidence; the payload follows its controlled schema. These concept labels are not JSON field names, wrapper keys or a wire format.
- Wrapper and payload
- Do not infer fields or schema from the illustration. Resolve both the envelope and payload definition from the published contract.
- Schema version and compatibility
- Do not select a default version or assume compatibility. Check the API documentation and Changelog for the published transition boundary.
- Correlation and minimization
- Use only permitted correlation references and minimal data. A correlation reference does not authorize access or prove current business state.
- Business / fiscal authority
- A valid envelope is not final truth. Follow the source-defined semantics and use authoritative API state where required.
Make uncertainty visible. Keep evidence minimal.
Use safe correlation and explicit currentness. Error meanings must come from controlled documentation; no error codes, live status or recovery deadline are supplied here.
- Verification failure
- Reject or quarantine under the governed procedure. Check required raw context and protected instructions; never downgrade to silent acceptance.
- Schema or version mismatch
- Stop assuming compatibility. Resolve the published schema and review the API Changelog before interpreting or processing the notification.
- Delayed / unknown status
- Keep status unresolved and avoid stale success. Consult source-defined delivery guidance and authoritative current API state where permitted.
- Recipient vs transport failure
- Distinguish the transport observation from receiver verification and consumer handling. A failed attempt does not establish a failed business outcome.
- Unresolved identity / correlation
- Investigate against the controlled identity contract. Do not invent identifiers or join unrelated private records to make the state appear resolved.
Minimal, redacted evidence
Keep permitted correlation, verification disposition and handling context. Mark whether an observation is current or unknown. Avoid raw payload logs and private identifiers.
Qualified support escalation
Use the authorized, source-controlled support process available to the integration context. Public guidance supplies no support endpoint, response SLA or entitlement.
Anatomy without invented production data.
Use this panel to recognize the kinds of contract information you must obtain—not as a payload, endpoint, subscription or implementation example.
Illustrative example — not a production event, endpoint or payload schema.
- Event
- <verified-event-label>
- Version
- <published-version>
- Correlation
- <correlation-reference>
- Delivery
- <contract-defined-state>
- Payload
- <source-controlled-schema-or-placeholder>
- Verification
- <controlled-procedure>
Text equivalent: the event label, version, correlation, delivery state, payload schema and verification procedure all require governed source data. This panel contains no secrets, hostnames, actual identifiers, versions or time values.
Unknown must stay unknown.
Illustrative reading states—not live service status. Core documentation remains readable when registry data, protected material or supplementary sources are absent.
Evaluate integration fit
Compare events, webhooks, API and bulk roles. Open the technical docs, then resolve published contracts before choosing a consumer design.
Check the trust boundary
Review protected verification, rejection and redaction requirements. No procedure, credential or secret is inferred from the public example.
Recover without stale success
Treat unknown or delayed observations as unresolved. Check controlled guidance and authoritative current state; do not reuse an old success label.
- Loading
- Loading governed registry information. Keep the contract guidance and related documentation visible; do not show sample records as loaded data.
- Empty / no published data
- No governed public event registry entries supplied in this view. Use the API Reference and integration guidance; this is not evidence of production absence.
- No match / reset
- No matching governed entries. Reset the search to review the supplied source; never expand the result with guessed events or versions.
- Registry unavailable
- Registry information is unavailable. Keep core docs readable and related routes visible. Do not substitute stale data as current registry truth.
- Version unknown
- The version cannot be established from the controlled source. Do not use a default; review the API Reference and Changelog before interpretation.
- Deprecated / withdrawn
- Display this state only when the governed source provides it. Review the published change boundary; do not assume migration or continued delivery.
- Restricted verification
- Protected verification instructions require the authorized process. Public conceptual guidance does not supply the restricted procedure or credentials.
- Payload unavailable
- The controlled schema or payload definition is not available in this view. Do not reconstruct fields from examples or assume a compatible format.
- Delivery contract-defined
- Read a delivery label only under its controlled semantics. No timing, retry or completion guarantee is inferred from the label.
- Changelog unavailable
- Change information is unavailable. Keep version and compatibility unresolved; do not treat missing change data as confirmation that nothing changed.
- No-JS / partial-CMS fallback
- Read the static core guidance and direct documentation routes. Registry enhancements are not required to understand the safety and authority boundaries.
Illustrative keyboard-focus state. Clear text labels and generous targets keep actions legible without color-only or hover-only meaning.
Readable without supplementary data
Core guidance and direct documentation routes do not depend on registry results, restricted instructions or supplementary change data. When a source is unavailable, keep uncertainty explicit rather than inferring success.
Direct answers. No invented contracts.
The documentation is the next step. Read the full boundary before designing a production consumer.
- What is this page for?
- It provides public event-driven integration guidance: contract discovery, verification boundaries, delivery semantics, replay safety and change control. It is not a production event catalogue or a subscription console.
- Where do actual event names and versions come from?
- Only from the governed, published contract source. No production registry entries are supplied in this view. Use the API Reference, integration guidance and API Changelog to resolve the controlled identity and version.
- Does a notification establish business or fiscal success?
- No. An event identity, delivery attempt, receipt or acknowledgement is not final authority. Read the source-defined purpose and follow the documented API/current-state checks where required.
- How should webhook material be verified?
- Preserve the required raw context and apply the governed protected procedure before trusted processing. Reject or quarantine unverifiable material. The exact algorithm, headers and validation windows are not supplied here.
- What delivery guarantees can I assume?
- None beyond what the controlled source actually states. This page does not supply retry timing, counts, ordering, retention, durability, latency, SLA or exactly-once guarantees.
- How should duplicates and replay be handled?
- Resolve controlled identity and correlation, check prior handling under the permitted history policy, and guard repeated effects. Consult authoritative API state if needed. Do not invent a TTL or rely on arrival order.
- What if delivery is delayed or status is unknown?
- Keep uncertainty explicit and do not display stale success. Review the source-defined delivery meaning, separate recipient from transport failure, and use current API state or the authorized support process where applicable.
- Where can I test safely?
- Start with the non-production Sandbox and controlled integration guidance. Confirm environment enablement and entitlement separately. Use no real customer, tax, tenant or secret data; sandbox guidance is not a production-readiness promise.
- Where are contract changes documented?
- Use the published API Changelog and versioned contract documentation. If change information is unavailable, keep compatibility unresolved rather than assuming that nothing changed.
Start with the contract. Then plan the integration.
Read the API Reference, integration guidance and change boundaries before making implementation or availability assumptions.