API SLA verification with evidence you can recheck
The Evidence Gateway helps a service buyer turn a measurable API-service agreement into a reviewable evidence package. Instead of relying only on a screenshot or a changing provider dashboard, keep the configured terms, sampled observations and calculation together. It is useful when an operator and buyer need to discuss a missed response-time target or review a proposed service credit. The tools are free to evaluate and do not require PVTY, a wallet connection or a payment.
What goes in: agreed terms and authorised observations
Start with the HTTPS endpoint you have permission to measure, the observation schedule and the service rules. State the thresholds, exclusions and credit limits before collecting evidence. The buyer-operated Node.js collector runs locally; it is not a hosted monitoring service. It records the supported HTTP observations and timing information for the scheduled probes. Do not supply credentials, confidential payloads or private-network targets. See the API SLA verification guide for measurement provenance and boundary examples.
What comes out: an inspectable package and a provisional credit report
Import the collected evidence and its matching contract into the Gateway. The evaluator keeps passing, failing, unknown and excluded observations distinguishable rather than treating missing samples as success. The report applies the configured credit rules and caps, then exposes the evidence behind the calculation. Export the supported CSV or JSON report, or use the print view to save a PDF for discussion. A report is a claim for review, not an invoice automatically accepted by a supplier.
Try the two-minute interactive invoice-review demo →
Try it: a $1,000 invoice and a $20 provisional credit
Choose Explore synthetic example above. The fictional agreement allows 1% per failed window, capped at 10%, with a 1,000 ms header-latency limit. Its six scheduled windows produce:
- HTTP 200 in 100 ms: one PASS.
- HTTP 503 and HTTP 200 in 1,300 ms: two FAILs.
- A timeout and a missing sample: two UNKNOWNs, not passes.
- Predeclared maintenance: one EXCLUDED window.
The calculation is $1,000 × min(10%, 2 × 1%) = $20. Coverage remains incomplete. A lower 1% cap would limit the claim to $10. These custom terms are not a standard vendor SLA, and no refund is issued.
To reproduce this offline, download worked-example.mjs and evaluator.mjs into one folder. With Node.js 24+, run node worked-example.mjs. The example checks the counts, credit and cap, creates an in-memory demonstration signing key, then confirms that altered evidence and rehashed tampering are rejected. It makes no network requests and saves no private key. The fresh demonstration key is not a PactVerity signing key. Compare the downloads with the published SHA-256 checksums before running them.
A correctly signed fictional example still does not prove an honest measurement or an independent identity. For real work, agree the terms and public key separately and keep the original observations.
How to verify the evidence offline
Keep the original contract, evidence files and expected signing public key together. Re-run the verification command from the downloaded package and compare the contract fingerprint and signature result. A valid signature helps detect changed bytes and identifies the signing key; it does not prove an organisation's identity or that the collector measured honestly. The developer documentation separates Gateway package verification from the standalone receipt verifier. The Integration Lab offers related fixtures for exploring the evidence model.
What the Gateway cannot establish
Samples are not proof of uninterrupted uptime. A period with no observation remains unknown; future scheduled samples are not completed checks. The collector is controlled by its operator, not an independent auditor. The tools do not establish whether an AI answer is semantically correct, move funds, enforce a contract, guarantee a refund or perform an independent security audit. Read the difference between deterministic checks and AI evaluation before selecting a method.
Choose the right starting point
Use the Proof Engine to evaluate supplied receipt inputs, or explore the service-evidence use cases before collecting a new run. For a structured project review, use the due-diligence checklist. Builders can inspect the Proof Programme and the limited meaning of a verification badge. Current security boundaries remain on the security page.