Service stub

A stub of the Signing API that answers the same calls without a signer, an app or a phone: trust-driver-stub-hash-signing.cleverbase.com, with its endpoint documentation at /docs. Use it to get your plumbing right before you involve a person.

Ask your Cleverbase contact for development and test credentials for it; they are separate from your acceptance and production clients.

What it is good for

• The shape of every call: the two authorizations, credentials/list, credentials/info, signHash, the encodings, the two tokens and their two roles.
• Your own state machine: the redirect handling, the state bookkeeping, the error branch, the timeouts.
• Getting a signature value back at all, so you can exercise your CMS assembly and your PDF writing end to end.

What it is not

• It does not trigger user interaction. No QR page to scan, no app request, no PIN. So it cannot show you what the signer sees, and it cannot catch a refusal that a real signer would give you.
• It never produces a real signature. What comes back is not a qualified signature and will not validate as one. A document built from it is for your own plumbing, not for a validator report you show anyone.
• It is beta, and the implementation may still change.

How to use it in a test suite

Point your CSC base URL at the stub and keep everything else identical. Our own reference integration does exactly that, with the base URL in an environment variable, which is what makes a stub-based test worth having: the code path under test is the one that runs in production.

Then move to acceptance (connect.acc.cleverbase.com) with a real phone for the things the stub cannot give you:

"Checks before you ship" is about the acceptance and production output; on the stub, the only thing you can check is that your own code did the right things in the right order.