Corobate is an embeddable attestation layer. Integrations are designed around the specific fields you need to attest, the systems those fields come from, and the audit obligations the resulting record has to satisfy.
Send requests to partners@corobate.com.
Each item below maps to a design decision on the Corobate side. The more of them a request answers, the faster the integration can be scoped.
| Item | Example | What it determines |
|---|---|---|
| Target application | SAP Ariba, NetSuite, a Django procurement service, an internal Node microservice | Which integration path fits — in-process SDK, sidecar service, gateway, or batch attestation. |
| Decision or approval step | Purchase-order release, supplier onboarding approval, batch disposition, shipment clearance | Where the attestation call is placed and what a hold means operationally in that workflow. |
| Fields to attest | Recycled content share, carbon footprint, cobalt provenance, state-of-health disclosure | The input schema, and which fields are sufficiency-critical versus disclosed context. |
| Systems those fields come from | Supplier master table, a lab PDF, an allowlisted registry endpoint, telemetry stream, an LLM summary | The field map, the default provenance class for each source, and the freshness horizon per field. |
| Evidence and provenance to preserve | Certificate identifiers, lab report numbers, observation timestamps, originator IDs, document hashes | What the receipt carries so it stands on its own as a record of diligence later. |
| Compliance or audit requirements | EU Reg 2023/1542 digital product passport, customer diligence questionnaire, internal SOX control, insurer evidence request | Retention, export format, anchoring depth, and what a verifier must be able to independently re-check. |
| Data residency and egress constraints | No data may leave the VPC; on-premises only; EU-resident storage | Whether the in-process build (no data egress) is required rather than a hosted path. |
| Volume and latency | ~500 attestations/day, must complete inside a 200 ms approval hook | Deployment shape, batching, and anchoring cadence. |
So a request can be written against something concrete: the engine takes a decision context and a set of classed inputs, and returns a sealed receipt carrying a verdict, a gated confidence, the binding constraint, and any named coverage gaps.
// called at the approval step you identify in your request const receipt = await attest({ decision_id: `po-release:${po.id}`, question: 'Is this purchase order releasable under our evidence policy?', domain: 'battery.procurement', actor: { id: actor.id, role: actor.role }, period_end: po.evaluation_period_end, policy: 'policy/po_release.json', // versioned, sealed into the receipt inputs: mapFields(po) // your field map, per the table above }) switch (receipt.verdict) { case 'APPROVE': return release(po, receipt) case 'CAUTION': return releaseWithConditions(po, receipt) case 'WITHHELD': return hold(po, receipt) // receipt names what is missing }
The receipt is content-addressed, chain-linked to the prior receipt in the ledger, and timestamped. Anyone holding it — an auditor, a customer, a regulator, a counterparty — can re-verify it without access to your systems and without trusting you.
Deeper detail before you write your request: For Technicians covers the verification checks, canonical encoding, field-map format and a step-by-step hook-in for an existing supply chain application. Nuts and Bolts covers the receipt construction and the math behind the gate.