Reference

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.

Credentials

The stub needs no registration. It has two shared test clients, and the one you authenticate with decides the key type: each sees exactly one credential. Any redirection URI is allowed.

Test clientClient IDClient SecretCredential ID
RSA-20486dd5f48d-bcd9-4a98-8a4c-5c82182f5be411628999-cb61-4c62-8e1f-09699dcb55216dd5f48d-bcd9-4a98-8a4c-5c82182f5be4
P-2565ee4ad61-e6f4-4541-9efc-534dae34a1b8bb60145b-e95a-4431-bdf1-23df33c23be7a9978217-1558-4772-b651-c85218787003

Run your flow once with each client to test both key types; see Change notice: ECDSA P-256 signing keys, section 6.1. These clients only exist on the stub and are separate from your acceptance and production clients (Registering your client).

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 trusted signature. The signature bytes are real and verify against the certificate in credentials/info, but that certificate is issued by a throwaway stub CA that nothing trusts. 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:

StubAcceptanceProduction
Call shapes, tokens, encodingsyesyesyes
The pages the signer sees, the app, the PINnoyesyes
Refusal and abort pathsnoyesyes
A signature that validatesno, the bytes verify but the chain does notyes, with test certificates, not qualifiedyes, qualified

"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.