# Signhost Developer Hub

> Entrust Signhost Developer Hub

## Docs

- [Introduction](/guide/start/introduction.md)
- [Quick Start](/guide/start/quick-start.md)
- [Authentication](/guide/features/authentication.md)
- [Form Sets](/guide/features/formsets.md)
- [Postbacks / Webhooks](/guide/features/postbacks.md)
- [Return URLs](/guide/features/return-url.md)
- [Sealing and seal-only transactions](/guide/features/sealing.md)
- [Signature Location](/guide/features/signature-location.md)
- [Signing Flows](/guide/features/signing-flows.md)
- [Statuses & Activities](/guide/features/status.md)
- [Form Fields in PDFs](/guide/guides/fillable-pdf-fields.md)
- [Multi-document Transaction](/guide/guides/multidocument-transaction.md)
- [multisigner-transaction](/guide/guides/multisigner-transaction.md)
- [signer-tag](/guide/guides/signer-tag.md)

## About

- [About Entrust Signhost](/about.md)

## Blog

- [Blog](/blog/index.md): Check here for the latest articles and release announcements about the Signhost REST API and SDKs.
- [Updated timezone information on data retrieval](/blog/post/2015-12-07-update-timezone-information-on-data-retrieval.md)
- [Deprecating Weak Algorithms](/blog/post/2025-04-01-deprecating-weak-algorithms.md): As part of our ongoing commitment to security best practices, we're announcing the deprecation of weak cryptographic hash algorithms in the Signhost REST API file upload endpoint. This change enhances the security of document integrity verification and aligns with modern cryptographic standards.

## Others

- [live-api](/live-api.md)
- [Download a file from a transaction](/openapi/files/downloadFile.md): Method: GET Path: /api/transaction/{transactionId}/file/{fileId} Retrieves a specific file from a transaction. The file is returned as a PDF document. The user must be the creator of the transaction to access the file.
- [Download receipt for a transaction](/openapi/files/getReceipt.md): Method: GET Path: /api/file/receipt/{transactionId} Downloads the receipt for a completed transaction (Status=30). The receipt contains information about the signing process and serves as proof of the completed transaction.
- [Upload PDF file or file metadata](/openapi/files/uploadFile.md): Method: PUT Path: /api/transaction/{transactionId}/file/{fileId} Upload either a PDF file or file metadata to a transaction. The Content-Type header determines which endpoint is used: application/pdf: Upload PDF file contentapplication/json: Upload file metadata Add a file to the transaction or overwrite an existing file with the same `fileId``. The file parameter can either be the PDF document or JSON metadata. If your file requires metadata, the JSON metadata MUST be supplied first. File digest header When uploading a file, it is possible to send a digest header along with the HTTP request. This header should contain a base64-encoded SHA checksum of the uploaded file. For more information on digest headers, refer to RFC 3230 for format instructions and RFC 5843 for the supported algorithms. Supported Algorithms Currently, only SHA-256 and SHA-512 are accepted as hash algorithms. While RFC 3230 originally included MD5 and SHA-1, these weaker algorithms are no longer supported for security reasons. Using SHA-256 or SHA-512 ensures compliance with modern security standards. For example: Digest: SHA-256=HtHRpLOZBEMnTpQS6Zn12veC4uhjtMwamfVAwmPQPmE=
- [Introduction](/openapi/index.md): A comprehensive REST API for creating, managing, and processing digital document signing transactions. This API enables developers to integrate secure electronic signature workflows into their applications, supporting multiple authentication methods, verification types, and document management features. Key Features Create and configure signing transactions with multiple signers and receiversSupport for various authentication methods (DigiD, SMS, itsme, etc.)Multiple verification options including digital certificates and biometric verificationFile upload and download with metadata supportReal-time transaction status tracking and webhook notificationsMulti-language support for international use casesComprehensive audit trails and receipt generation Important Notes All input strings should be UTF-8 encodedOptional JSON properties should be omitted when not usedDo not provide null valuesDo not perform active polling for transactions status updates. Use the postback service instead. For detailed integration guides and examples, visit the Signhost Developer Documentation. Contact Servers Authentication API Operations API Models
- [Activity](/openapi/models/Activity.md): Activity/event information for a signer (based on ActivityGetDto) Properties
- [CreateReceiverRequest](/openapi/models/CreateReceiverRequest.md): Receiver configuration for getting copies of signed documents Properties
- [CreateSignerRequest](/openapi/models/CreateSignerRequest.md): Request object for creating a new signer in a transaction. Defines the signer's identity, authentication/verification requirements, notification preferences, and signing behavior. Key Requirements: Email address is mandatoryEither Authentications or Verifications must be provided (or both)Signers with AllowDelegation enabled cannot have AuthenticationsSendSignRequest determines if sign request emails are sent automatically Properties
- [CreateTransactionRequest](/openapi/models/CreateTransactionRequest.md): Transaction creation data including signers, receivers, files, and configuration. This is the request body for creating a new transaction. Properties Example:
- [ErrorResponse](/openapi/models/ErrorResponse.md): Error response object based on RFC 7807 Problem Details for HTTP APIs. See https://datatracker.ietf.org/doc/html/rfc7807 for details. Response Format: A response is either in the new RFC 7807 Problem Details format OR the legacy Message format, but never both. New Format (RFC 7807): Contains the type property and standard problem detail properties (title, detail, status). May also include additional extension members.Legacy Format: Contains only the Message property. This format is used for some existing error responses during our transition to full RFC 7807 compliance. Usage: Check if the type property is present. If it exists, the response is in RFC 7807 format. If type is absent, fall back to reading the Message property. Properties Examples: Modern RFC 7807 Problem Details format Legacy error response format
- [FileEntry](/openapi/models/FileEntry.md): File information and metadata associated with a transaction. Contains details about uploaded documents including display properties, download links, and current processing status. Files are referenced by their unique identifier within the transaction and can include PDFs, receipts, and other document types. Properties
- [FileField](/openapi/models/FileField.md): Represents an individual form field or signing area within a document. Fields define where and how users interact with the document during the signing process. Properties
- [FileFieldLocation](/openapi/models/FileFieldLocation.md): Defines the precise positioning and sizing of a field within the PDF document. Fields can be positioned using absolute coordinates or by searching for specific text anchors within the document. Properties
- [FileFieldType](/openapi/models/FileFieldType.md): Specifies the type of interaction or data entry required for this field. Different types have different behaviors and validation rules in the signing interface. Possible values: Seal, Signature, Check, Radio, SingleLine, Number, Date Example:
- [FileMetadata](/openapi/models/FileMetadata.md): Comprehensive metadata information for a file in a transaction. This metadata defines how the file should be displayed, processed, and what form fields and signing areas it contains. The metadata can be uploaded before or after the actual PDF file. Properties
- [FileSignerData](/openapi/models/FileSignerData.md): Configuration data specific to a signer for a particular file. This determines which form sets the signer needs to complete when signing the document. Properties
- [Link](/openapi/models/Link.md): URI link with relationship and type information Properties
- [Receiver](/openapi/models/Receiver.md): Receiver information (based on ReceiverGetDto which extends ReceiverBaseDto) Properties
- [Signer](/openapi/models/Signer.md): Signer information with current status (based on SignerGetDto which extends SignerBaseDto) Properties
- [SignerAuthentication](/openapi/models/SignerAuthentication.md): Authentication methods used to verify signer identity before document access. These methods must be completed before the signer can view documents. Important: The "Type" property is case-sensitive and must be capitalized. Discriminator This is a polymorphic schema that uses the Type property to determine the specific type. One Of Schemas The following schemas can be used: SignerPhoneNumberIdentificationSignerDigidIdentification
- [SignerConsentVerification](/openapi/models/SignerConsentVerification.md): Consent-based verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerCscVerification](/openapi/models/SignerCscVerification.md): Cloud Signature Consortium (CSC) verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerDigidIdentification](/openapi/models/SignerDigidIdentification.md): Dutch DigiD verification Parent Types This model is a variant of the following polymorphic types: SignerAuthenticationSignerVerification Properties
- [SignerEHerkenningVerification](/openapi/models/SignerEHerkenningVerification.md): eHerkenning business identity verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerIDINVerification](/openapi/models/SignerIDINVerification.md): iDIN bank identification verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerIDealVerification](/openapi/models/SignerIDealVerification.md): iDEAL bank verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerIPAddressVerification](/openapi/models/SignerIPAddressVerification.md): IP address verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerItsmeIdentificationVerification](/openapi/models/SignerItsmeIdentificationVerification.md): itsme identification verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerOidcIdentification](/openapi/models/SignerOidcIdentification.md): OpenID Connect identification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerOnfidoIdentification](/openapi/models/SignerOnfidoIdentification.md): Onfido identity verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerPhoneNumberIdentification](/openapi/models/SignerPhoneNumberIdentification.md): SMS phone number verification Parent Types This model is a variant of the following polymorphic types: SignerAuthenticationSignerVerification Properties
- [SignerScribbleVerification](/openapi/models/SignerScribbleVerification.md): Handwritten signature verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerSurfnetVerification](/openapi/models/SignerSurfnetVerification.md): SURFnet academic verification Parent Type This model is a variant of the following polymorphic type: SignerVerification Properties
- [SignerVerification](/openapi/models/SignerVerification.md): Verification methods used to confirm signer identity before document signing. These methods must be completed before the signer can sign documents. Important: The "Type" property is case-sensitive and must be capitalized. Critical Requirement: You must use one of the following verification methods as the last verification in your verifications list: ConsentPhoneNumberScribbleCSC Qualified* Rules for CSC Qualified: This method must always be the absolute final verification - nothing can come after it Rules for Consent, PhoneNumber, and Scribble: These three can be used as the final verification methodThey are commonly used when you want additional verification steps before the final consent/signature Common Mistakes: Using only authentication methods (e.g., iDIN) without a final verification methodPlacing verifications after CSC Qualified Valid Examples: [Consent] ✓[iDIN, Consent] ✓[iDIN, PhoneNumber] ✓[iDIN, CSC Qualified] ✓[CSC Qualified, Consent] ✗ (Nothing can come after CSC Qualified)[iDIN] ✗ (Missing required final verification) Discriminator This is a polymorphic schema that uses the Type property to determine the specific type. One Of Schemas The following schemas can be used: SignerScribbleVerificationSignerPhoneNumberIdentificationSignerDigidIdentificationSignerIDealVerificationSignerSurfnetVerificationSignerIDINVerificationSignerIPAddressVerificationSignerEHerkenningVerificationSignerItsmeIdentificationVerificationSignerConsentVerificationSignerCscVerificationSignerOidcIdentificationSignerOnfidoIdentification
- [Transaction](/openapi/models/Transaction.md): Complete transaction data returned when retrieving or creating a transaction. Includes all configuration, current status, and file information. Properties
- [TransactionDeleteOptions](/openapi/models/TransactionDeleteOptions.md): Options for cancelling a transaction Properties
- [Create Transaction](/openapi/transactions/createTransaction.md): Method: POST Path: /api/transaction Create a new transaction for document signing. A transaction contains signers, receivers, and configuration for the signing process. After creating a transaction, you can upload files and start the signing process. Important Notes: If Seal is false, at least one signer must be providedProviding no signers with Seal true allows for automatic sealing.Signers with AllowDelegation enabled cannot have authenticationsIf any signer has SendSignRequest enabled, SignRequestMode defaults to 2Authentication array requires explicit versioning header (Accept: application/json;version=1)The Type property in authentication/verification objects is case-sensitive and must be capitalized
- [Delete / Cancel a Transaction](/openapi/transactions/deleteTransaction.md): Method: DELETE Path: /api/transaction/{transactionId} Cancelling a Transaction When a transaction is not in an end-state (eg. Status = 5, 10, or 20) the transaction will be cancelled and deleted. When cancelling a transaction, you can choose to send an email notification to any awaiting signers informing them that the transaction has been cancelled. The status of the transaction will be set to cancelled. Deleting a Transaction When a transaction is in an end-state (eg. Status = 30, 40, 50, or 60) the transaction will be deleted. When deleting a transaction, you can choose to send an email notification to any awaiting signers informing them that the transaction has been deleted. The status of the transaction will remain the same but any uploaded documents and sensitive data will be deleted as soon as possible.
- [Get a transaction by ID](/openapi/transactions/getTransaction.md): Method: GET Path: /api/transaction/{transactionId} Retrieve transaction details including signers, receivers, files, and current status. Do not use this method for active polling. Use the postback service instead.
- [Start a transaction](/openapi/transactions/startTransaction.md): Method: PUT Path: /api/transaction/{transactionId}/start Start the signing process for a transaction. All required files and signers must be configured before starting. Once started, the transaction cannot be modified and signers will be notified to begin signing.