When you sign a PDF through Cleverbase, the work is split in two:
| Cleverbase | You (the integrator) |
|---|---|
| Identifies the signer and holds their qualified certificate and key. | Prepare the document: fields, appearance, the reserved space for the signature. |
| Authorizes one signature at a time, with the signer's consent. | Compute what has to be signed and send us its hash. |
| Signs that hash with the signer's qualified key and returns the signature value. | Put the signature value into a CMS structure and that structure into the PDF. |
| Validate the result and check how it looks in the viewers your users have. |
The service you talk to is a Cloud Signature Consortium API, version 1.0.4, with OAuth 2.0 for the two authorizations involved. It is deliberately a hash-signing API: Cleverbase never sees your document, only a hash. That is good for confidentiality and it is why the document construction is on your side.
What that split means for you
Because we only ever see a hash, everything about the document is yours: which field the signature goes in, how it looks, whether the form stays editable, how much room the signature gets, and whether the file still shows a signature in every viewer your users have. None of that is checked by the API, and none of it is visible to a validator either. That is why most of this documentation is about the PDF and not about the three API calls: the calls are the same for everyone, the document is where integrations differ, and where they go wrong.
It also means the same three calls serve any container. This documentation works out PAdES, a signature inside a PDF, because that is where the questions come from. CAdES (a signature over any file) and XAdES (XML) use the same hash-signing step with a different wrapper, and are mentioned where the difference matters.
The reference implementation
Cleverbase runs its own integration of this exact flow, and the code samples in this documentation are cut from it. The PDF side is a small Java service on DSS 6.3 (prepare and complete endpoints); the CSC side is a Python application that performs the OAuth legs, the credential lookup and signHash. Where a page says "our implementation does X", it refers to that code, and X is a choice that has been in production use, not a recommendation from a specification alone.
Where to go from here
The hosts and what you need before the first call are in Environments and prerequisites. The steps themselves are the how-to guides, starting with The signing flow; what the signer goes through in the meantime is The signer's journey.