When the security team brings Certyo to engineering, the first question is rarely "does it work?" — it is "how invasive is the integration?" The honest answer is: less than people expect. Adding tamper-evident integrity to an existing service is a single HTTP call on the write path, no changes to the read path, and a small operational addition for verification. This post walks through what that looks like in real code, what the production-grade version adds on top of the minimal version, and where the actual engineering cost lives.
The minimal integration
If you have a service that writes records to a database, the minimum addition is a single POST to /api/v1/records after each write. The request body is the record itself plus tenant identifiers. The response is a 202 Accepted with a record identifier you can store alongside your row.
Read paths do not change. Your application continues to read from your database exactly as before. The integrity proof is computed on demand at verification time — not at every read. This is the design choice that keeps the integration small: integrity is an additive write-path concern, not a read-path rewrite.
What the code actually looks like
Three concrete examples — Node, Go, Python — for the same minimal integration. Each is roughly 5 lines of new code added to an existing write handler:
- Node — `await fetch(url, { method: 'POST', headers, body: JSON.stringify({ tenantId, clientId, record }) })` immediately after your existing INSERT. The fetch is fire-and-forget for the happy path; the 202 response confirms the record entered the ingestion queue.
- Go — a single `http.Post` call with the same payload shape. Wrap it in a goroutine if you want non-blocking writes, or call synchronously if you want hard durability before returning to the user.
- Python — `requests.post(url, json={'tenantId': ..., 'clientId': ..., 'record': ...})` next to your existing ORM save. The library handles connection reuse and retry-on-network-failure if you configure a session.
What the production-grade version adds
The 5-LOC version is real and works for staging or proof-of-concept. The production version adds three things on top: idempotency keys so a retried request doesn't double-anchor, a local outbox so transient network failures don't drop records, and structured error handling so anchoring failures don't break user-facing writes. None of these are Certyo-specific — they are the same patterns you'd use for any out-of-process side effect.
The production-grade version is closer to 30 to 80 lines including idempotency, outbox, and observability. That is still small in absolute terms — comparable to adding any internal service call with at-least-once semantics. The reason engineers reach for tools like Outbox or Debezium is the same reason they apply here: durable side effects on the write path are a solved problem.
Where the integration actually flows
The end-to-end flow from your application to a verifiable proof on-chain has five stages. Your code only participates in the first one. Everything after is operated by the platform — there is nothing to integrate, nothing to maintain, nothing to scale on your side:
The verification step is where a different code path matters: when an auditor or downstream consumer wants to prove a record is intact, they call POST /api/v1/verify/record. That call is also single-line. The verification result is deterministic and re-runnable by any third party against the on-chain Merkle root. This is the part that goes in the evidence package handed to compliance, not in your application code.
Where the actual engineering cost lives
The 5-LOC framing is honest about the integration but it can hide three places where real engineering thinking is required. None of them are blocking, but engineers should know about them upfront:
- Idempotency design — If your write handler can retry on failure — and most well-built handlers do — you need to make sure retried requests do not produce duplicate anchored records. The platform supports idempotency keys; the engineering decision is which natural key in your data is stable enough to use as the idempotency key (typically a record UUID or a transaction identifier).
- Failure-mode policy — If the anchor call fails, what should the user-facing write do? Block until anchoring succeeds (strong durability, higher latency)? Proceed and reconcile later (better latency, requires an outbox)? This is a policy decision that depends on the criticality of the record. Most teams pick reconcile-later for the bulk of records and synchronous anchoring for a small high-stakes subset.
- Verification surfacing — The minimal integration anchors records but does not surface verification to end users. If your application needs to show "this record was verified at X timestamp" in the UI, that is a small additional integration on the read path. It is not free, but it is also not where most teams start.
What to ask for from your engineering reviewer
If a security or compliance lead is reviewing Certyo with engineering, the right ask is a one-day spike: stand up the staging integration with the 5-LOC version, run it against a representative subset of writes, observe the result in the verification UI, and write down the production-grade gaps (idempotency key, outbox, error policy). That output is a credible internal estimate for the full integration. It is also a working staging environment, which makes the next-stage decision concrete instead of theoretical. For the verification API in detail, see the developer portal. For deployment topologies, see /en/about.
Adding integrity to a write path is a single HTTP call. Read paths do not change. The engineering work that remains — idempotency, retry, observability — is the same work you would do for any durable side effect. There is no surprise.