Repository navigation
Certificates and Signing API
These APIs require user authentication and the relevant certificate or signature permissions. Cryptographic signing additionally needs configured signing services and keys. Never include real key material in a public example or support report.
Prefix paths with /api/v1/certificates.
| Method | Suffix | Permission / purpose |
|---|---|---|
| GET |
/, /{id}, /default
|
certificates:read; list, detail, or default |
| POST | /generate |
certificates:manage; generate an offered self-signed certificate |
| POST | /upload |
certificates:manage; register supported certificate material |
| PUT | /{id}/default |
certificates:manage; choose default |
| DELETE | /{id} |
certificates:manage; remove under service rules |
Generation requires name (1–255 characters). Optional input includes commonName, organization, organizationUnit, algorithm (RSA_2048, RSA_4096, ECDSA_P256, ECDSA_P384), validity days (30–3,650, default 730), country, state, locality, and email. Defaults and selectable values do not guarantee a deployed signer supports every algorithm.
Upload requires name and certificatePem. The schema also supports chain, algorithm, and timestamp-service URL. Private-key provisioning, where required, must follow the deployment operator's approved secure process; it is intentionally not illustrated with key material here. Registering a public certificate alone does not guarantee the signing service possesses its usable private key.
Prefix paths with /api/v1/signing.
| Method | Suffix | Input |
|---|---|---|
| POST | /seal/{agreementId} |
Optional certificateId, pdfData; requires signatures:sign and eligible state |
| POST | /batch |
Required agreementIds UUID array, 1–100; optional certificateId; requires signatures:sign
|
| POST | /verify |
token, hash, or fileData; authenticated verification |
Sealing creates evidence on a real document. Do it only through an approved workflow and check the actual result. A completed agreement state, a stored certificate, or a successful HTTP request does not independently prove a particular PAdES level or trusted timestamp.
Public verification and report download routes are in REST API Reference. Read Cryptographic Signing and Verification before interpreting results.
The /csc/v2 family exposes POST routes /info, /credentials/list, /credentials/info, /credentials/authorize, /signatures/signHash, and /signatures/timestamp. Credential operations and signature hash operations have relevant authorization requirements. The protocol label alone does not certify CSC conformance; validate interoperability with the operator before adopting this interface.
Documentation home · Getting started · Troubleshooting · Feature availability
Reviewed 3 October 2026.
graphsign.ink
Using the application
Account and administration
Developer documentation
- API quick start
- REST API reference
- Agreement and workflow API
- Template API
- Account and organization API
- Search API
- Certificates and signing API
- Webhooks and integrations
- Feature availability
Help