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 client | Client ID | Client Secret | Credential ID |
|---|---|---|---|
| RSA-2048 | 6dd5f48d-bcd9-4a98-8a4c-5c82182f5be4 | 11628999-cb61-4c62-8e1f-09699dcb5521 | 6dd5f48d-bcd9-4a98-8a4c-5c82182f5be4 |
| P-256 | 5ee4ad61-e6f4-4541-9efc-534dae34a1b8 | bb60145b-e95a-4431-bdf1-23df33c23be7 | a9978217-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
statebookkeeping, 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:
| Stub | Acceptance | Production | |
|---|---|---|---|
| Call shapes, tokens, encodings | yes | yes | yes |
| The pages the signer sees, the app, the PIN | no | yes | yes |
| Refusal and abort paths | no | yes | yes |
| A signature that validates | no, the bytes verify but the chain does not | yes, with test certificates, not qualified | yes, 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.