sichtbar-xovi

Protected XOVI credit and Monitoring OVI operations for self-hosted n8n.

Package Information

Released: this month
Downloads: 0 weekly / 0 monthly
Latest Version: 0.1.2
Author: Sichtbar Online Marketing AG

Documentation

SICHTBAR XOVI for n8n

Version 0.1.2; CommonJS, Node.js 20+, tested with n8n 1.110.1. No runtime dependencies or installation scripts.

Credential

Create a SICHTBAR XOVI API credential and enter the API key in its password field. n8n supplies credential encryption at rest. The key is used only at runtime in the TLS request path required by XOVI; it is never placed in workflow parameters or returned data. No automatic credential test. Do not enable HTTP tracing or NODE_DEBUG: this library cannot protect secrets from privileged host instrumentation or process dumps.

Operations

  • getCreditstate: numeric balances only; zero XOVI credits.
  • getOviTrend: explicit project hash, numeric search-engine ID, device 1/2/3, measurement period, run ID, project ID, domain and scope version. Monitoring OVI only; never static OVI.

Selection and pagination

Page inspection accepts a nonnegative page index (skip), not a row offset, and one or two rows. It returns numeric page metadata, a sanitized observation and no writable KPI records. A page alone does not prove the latest observation.

Verified selection reserves a bounded credit budget before every page request. It starts at page zero; an unfiltered resultCount can suggest one bounded tail probe, but is never trusted as proof of the last scoped page. No retries. A result is proven latest within the requested date scope only when it matches the final possible day in that scope, or every contiguous page from zero has been exhausted. Unordered, ascending and descending rows are handled identically. Repeated pages, conflicting daily values, inconsistent credits, incomplete coverage and out-of-period data produce no writable KPI. The actual measurement date is retained.

The date upper bound is the earlier of the final day of the exclusive-ended measurement period and today's Europe/Berlin date. A closed weekly period proves a weekly snapshot, not the latest observation outside that week. Provider date/default behavior is not assumed to sort, reverse or reliably filter rows. Live behavior of this correction still needs validation in an authorized bounded run.

Credit controls

Paid approval defaults to false and budget to zero. Inspecting one/two rows requires exactly 5/10 credits of approval. Verified selection accepts an explicit total cap up to 150 credits (multiples of 5), including every candidate and fallback request. Each request reserves 5 credits per allowed result row, including empty terminal requests. Free credit checks bracket the sequence. Concurrent account use can invalidate balance attribution; a mismatch stops processing. A recent candidate is not emitted as a KPI if selection remains unproven.

A common two-probe path allows at most 10 credits per project when the count hint locates the requested final day. This is an upper bound for that path, not a promise of successful latest selection. Long histories or ineffective provider filtering may need more credits; the configured cap always wins. Do not enable unbounded historical scans.

Output and compatibility

Existing node and credential type names are unchanged. records contains at most one weekly monitoring KPI with its real measurement date, method, scope and device dimension. selection_complete, selection_proof, selection_upper_bound, observed date/value, numeric page metadata and credit totals make selection auditable. Out-of-period observations are diagnostics only. Existing workflows must explicitly select verified mode and pass confirmed mapping/context before a paid run.

No new infrastructure is required. Public registry publication, production installation and execution require their own authorization. All local tests use invented secrets and simulated responses.

Discussion