Every signature API returns an audit report the vendor vouches for

Embed a signature vendor into your product and you inherit a dependency that outlives the contract. Two years later a customer disputes an agreement, and confirming what happened means asking the vendor — who may have changed their API, their pricing, their retention policy, or their owner.

That is the actual risk in this category, and it is not usually the one that gets evaluated. The evaluation is about fields, templates and webhooks.

Two backends, and the split is deliberate

The signing engine is a module inside a Rutba instance — yours if you are licensed, a shared one otherwise. That is where envelopes are created, sent and sealed, beside the documents it signs.

The public surface is served by the platform: verification, the published key set, abuse reporting. Two different systems, and the reason is a single sentence — a counterparty verifying your document never touches your systems and never needs anything from you.

• They do not need an account.
• They do not need a key.
• They do not need your instance to be up.
• They do not need to pay anybody. Verification is free and stays free.

A record only checkable by asking the vendor is a record about the vendor.

What comes back

Documents pinned by hash, the events hash-chained, and the completion manifest sealed and timestamped by a public RFC 3161 authority. The key set is published, so the seal can be checked without asking us anything.

Verification also works on a single party’s receipt, not only a completed envelope. Every act is countersigned by the platform the instant it happens — so somebody who signs today and waits three weeks for the other parties holds independently checkable proof of their own act immediately.

What building against it looks like

• A REST API with scoped, revocable bearer keys (sgk_…) at /api/sign/v1.
• Signed webhooks on every envelope event.
• A typed SDK generated from the same routes the engine serves — so an API change is a compile error rather than a support ticket.
• Templates and bulk send through the same API.
• The identity ladder chosen per signer: email, phone code, access code, location.
• The agreement lifecycle too: compose in one call, then calendars, renewals and formalities with their stages.

The generated SDK is the detail worth pausing on. A hand-written client drifts from the API it wraps, and the drift is discovered in production by a customer. A client generated from the routes cannot drift — at worst it fails to compile, which is the cheapest possible place to find out.

The same envelope, through a different door

The envelope rate is identical to the application tier of Rutba Sign, because it is the same metered envelope arriving through a different door. Charging more for the API would be charging for the absence of a user interface.