Български
Borica logo B-Trust logo B-trust Moble Efactura logo
Search icon
Header clients image
Home > Services

Services

For developers

Contents

How to get started I want to... Common concepts
Scenarios and operations Compact operation index Swagger links
Requesting access Testing and production readiness Contacts
Postman collections Additional services Frequently asked questions

How to get started

1. Select a scenario from the “I want to...” section.
2. Review the process — which steps are performed and which operations are involved.
3. Open the relevant Swagger for exact parameters, request/response models and response codes.
4. Request access to the test environment and required operations.
5. Register an SSL certificate and use the provided relyingPartyId for active requests.
6. Test successful and declined scenarios before moving to production.

I want to...

This section is a quick entry point to the documentation based on the developer’s task. Each card shows the relevant scenario, the main API and the key operations involved. Detailed parameters remain in Swagger.

Check whether the client has an active cloud QES

Used before signing when you need to establish whether the client has a profile/certificate and how the client should be addressed.

API: Signing API

Main operations: checkclient, getCert, clientAuth

  
Send a document for signing through B-Trust Mobile

The standard scenario for signing a PDF, contract, application or another document by a specific user.

API: Signing API

Main operations: sendSignRequest, getSignedResult, getSignedContent
Implement signing via QR code

Suitable when the user scans a QR code with B-Trust Mobile and selects the signing certificate.

API: Signing API

Main operations: sendSignRequestViaQR, getSignedResult, getSignedContent

  
Sign a document package

Used when multiple documents must be processed as one parcel/common process.

API: Signing API

Main operations: sendParcelSignRequest, getParcelDetails, download parcel
Track document delivery/service

Operations related to viewing, status, received parcels and delivery evidence/receipt.

API: Signing API

Main operations: received-parcel-usage, parcel/viewed, evidence/receipt

  
Sign with a one-time cloud QES

OTC scenario for one-time document signing without the standard use of B-Trust Mobile as a permanent channel.

API: Signing API / OTC

Main operations: otc/sign, otc/content, otc/archive
Identify a user remotely

Web identification or identification through B-Trust Mobile, depending on the selected process and channel.

API: Remote Identification API

Main operations: identification, websession/start, status/result

  
Perform web identification followed by OTC signing

End-to-end flow for identification, sign session creation, OTP confirmation and signing.

API: Remote Identification API / OTC

Main operations: create sign session, generate OTP, validate OTP
Implement automated/server-side signing

For processes with prior consent, accessToken and signing without separate user confirmation for each operation.

API: Automatic Remote Signing API

Main operations: consent, arsign/sync, batch/async

  
Use an OIDC-based signing process

OIDC scenario for a signing request, obtaining a result and user data.

API: OIDC API

Main operations: oidc/sign, sign/result, user-data

Common concepts

Concept Meaning for the integration
relyingPartyId Identifier of the relying party. It is used in active API operations and is provided by BORICA.
rpToClientAuthorization Header through which the relying party specifies how the client is identified — for example personalId, certId, profileId or clientToken.
callbackId Request identifier returned by the API. It is used to check status, obtain a result or download content.
rpCallbackId Identifier set by the relying party. It is used when the client system wants to manage process correlation itself.
OTC One-time cloud qualified electronic signature/certificate used for a specific process or signing.
Callback / Pull In asynchronous processes, the result can be received through a callback to the relying party or through a status check operation.

Scenarios and operations

These sections answer the question “What exactly should I call to implement a given functionality?”. They contain only the operational sequence and the purpose of each operation.

▸ User check and identifier selection

Use when: you need to determine whether the user has an active cloud QES, which certificate to use, or how to address the user in the next request.

Do not use when: this is not a standalone signing service; it is used as preparation before signing, authentication or automated signing.

# Step Operation Role in the integration
1 Check for active cloud QES GET /signing-api/v2/sign/checkclient
getCustomerWithActiveCQESUsingGET		 Checks whether a client has an active cloud qualified electronic signature.
2 Get certificate by profileId GET /signing-api/v2/cert/{profileId}
getCertUsingGET		 Returns the client’s X.509 certificate by profileId.
3 Get certificate by identifier GET /signing-api/v2/cert/identity/{identificatorType}/{identityValue}
getCertByPersonalIdUsingGET		 Returns the client’s X.509 certificate by identifier type and value.
4 Get client token POST /signing-api/v2/auth
clientAuthUsingPOST		 Issues a client token for a user based on profileId and OTP/authorization code.
Expected result: you select a stable way to address the client: personalId, certId, profileId or clientToken.
▸ Signing a single document through B-Trust Mobile

Use when: the user needs to receive a document in B-Trust Mobile, sign or reject it, and the relying party system needs to receive the signed result.

Do not use when: for QR signing, a document package or automated signing without user confirmation, use the respective separate scenarios.

# Step Operation Role in the integration
1 Create request POST /signing-api/v2/sign
sendSignRequestUsingPOST		 Creates a signing request for a document/file to a B-Trust Mobile user.
2 Check by callbackId GET /signing-api/v2/sign/{callbackId}
getSignedResultUsingGET		 Checks the status/result of a signing request by callbackId.
3 Check by rpCallbackId GET /signing-api/v2/rpcallbackid/{rpCallbackId}
getSignedResultByRpCallbackIdUsingGET		 Checks a signing result by the relying party callback identifier.
4 Download signed document GET /signing-api/v2/sign/content/{id}
getSignedContentUsingGET		 Downloads a signed document by content identifier.
Expected result: when the status is successful, you receive an identifier of the signed content and download the signed file.
▸ Signing via QR code

Use when: the user scans a QR code with B-Trust Mobile and selects a signing certificate.

Do not use when: not suitable if the process must be automatically directed to a specific user without scanning.

# Step Operation Role in the integration
1 Create QR request POST /signing-api/v2/signviaqr
sendSignRequestViaQRUsingPOST		 Creates a signing request via QR code to be scanned with B-Trust Mobile.
2 Check status/result GET /signing-api/v2/sign/{callbackId}
getSignedResultUsingGET		 Checks the status/result of a signing request by callbackId.
3 Download signed document GET /signing-api/v2/sign/content/{id}
getSignedContentUsingGET		 Downloads a signed document by content identifier.
Expected result: you receive a QR code and callbackId. After scanning and signing, you download the signed document.
▸ Signing a document package/parcel

Use when: several documents must be processed as one common process — for example a set of contracts, applications or client file documents.

Do not use when: for a single document, when grouping, common status or package download is not required.

# Step Operation Role in the integration
1 Create parcel request POST /signing-api/v2/sign/parcel
sendParcelSignRequestUsingPOST		 Creates a request for signing a document package/parcel.
2 Bind to certificate POST /signing-api/v2/sign/bindSignRequest/parcel/
bindParcelSignRequestUsingPOST		 Binds a parcel signing request to the selected certificate.
3 Check details GET /signing-api/v2/sign/parcel/details/{uuid}
getParcelDetailsShortUsingGET		 Returns short parcel data by uuid.
4 Download signed documents GET /signing-api/v2/sign/parcel/download
getSignedParcelDocumentsUsingGET		 Downloads the signed documents from a parcel.
5 Reject parcel POST /signing-api/v2/sign/parcel/reject
rejectParcelSignRequestUsingPOST		 Rejects a parcel signing request.

Postman examples:

Collection: Parcel_Integration

Covered requests: Check client, Send parcel sign request, Get parcel details, Download signed parcel, Reject parcel sign request

Open Postman collection
Expected result: you receive signed documents individually or as a package, depending on the operation result.
▸ Service, delivery and evidence

Use when: you need to track a received parcel, mark it as viewed, or download evidence/receipt.

Do not use when: does not replace signing itself; these are operations around the parcel/delivery lifecycle.

# Step Operation Role in the integration
1 List of received parcels GET /signing-api/v2/received-parcel-usage/list
getReceivedParcelUsageContentUsingGET		 Returns a list of received parcels/usage content and statuses.
2 Mark as viewed POST /signing-api/v2/sign/parcel/viewed
changeStatusToViewedUsingPOST		 Marks registered mail/parcel as viewed.
3 Download evidence GET /signing-api/v2/sign/evidence/receipt
getEvidencePDFUsingGET		 Downloads PDF evidence/receipt for the specified messageIdentifier.
Expected result: you receive statuses, usage information and an evidentiary document for the delivery/service.
▸ One-time QES signing when the data/session is prepared

Use when: you need to send documents for signing with a one-time cloud qualified electronic signature and download the result.

Do not use when: does not cover a full web identification process; for that, use the web identification + OTC scenario.

# Step Operation Role in the integration
1 Start OTC signing POST /signing-api/v2/otc/sign
signOtcDocumentsUsingPOST		 Starts document signing with a one-time cloud qualified electronic signature.
2 Download signed content GET /signing-api/v2/otc/content/{id}
getOTCSignedContentUsingGET		 Downloads signed content by an identifier obtained after OTC signing.
3 Archive OTC documents POST /signing-api/v2/otc/archive
archiveOtcDocumentsUsingPOST		 Archives documents signed with OTC in the long-term storage service.
Expected result: you receive signed content from the OTC process and archive it if needed.
▸ One-time QES — issuance and signing in one session

Use when: the process includes personal data validation, session creation, document upload, OTP confirmation and downloading the signed documents.

Do not use when: if identification is performed through the Remote Identification API web flow, see the “Web identification + OTC” scenario.

# Step Operation Role in the integration
1 Create OTC session POST /signing-api/v2/otc/issueAndSign/startSession
createOTCIssueRequestUsingPOST_1		 Validates personal data and creates an OTC issue-and-sign session.
2 Check session GET /signing-api/v2/otc/issueAndSign/checkSession
checkSessionUsingGET		 Checks the status of the OTC issue-and-sign session.
3 Upload documents PUT /signing-api/v2/otc/issueAndSign/signDocs
sendDocsForSigningUsingPUT		 Uploads documents to the OTC session and starts SMS/OTP confirmation.
4 Validate OTP POST /signing-api/v2/otc/issueAndSign/validateOTP
validateOTPCodeUsingPOST		 Validates the OTP code and finalizes the OTC issue-and-sign process.
5 Download signed documents GET /signing-api/v2/otc/issueAndSign/getSignedDocs
getSignedDocumentsUsingGET		 Downloads the documents after OTC signing.
Expected result: a finalized session with signed documents and trackable status.
▸ One-time QES v2 — documents or digests

Use when: you need to work with an OTC v2 flow, including submitting documents or digests for signing.

Do not use when: do not mix v1 and v2 operations in one integration without an explicit technical reason.

# Step Operation Role in the integration
1 Create v2 session POST /signing-api/v2/otc/issueAndSign/v2/createSession
createOTCIssueRequestUsingPOST		 Validates personal data and creates an OTC issue-and-sign v2 session.
2 Issue OTC via OTP POST /signing-api/v2/otc/issueAndSign/v2/issueOTC
issueOTCCertificateUsingPOST		 Sends an OTP to start the OTC issuance process.
3 Get issued OTC GET /signing-api/v2/otc/issueAndSign/v2/certificate
getOTCCertificateUsingGET		 Returns the issued one-time certificate.
4 Upload documents/digests PUT /signing-api/v2/otc/issueAndSign/v2/sendDocs
sendDocsDigestForSigningUsingPUT		 Uploads documents or digests for signing in the OTC v2 process.
5 Download signed documents/digests GET /signing-api/v2/otc/issueAndSign/v2/getSignedDocs
getSignedDocumentsDigestUsingGET		 Downloads the signed documents/digests after OTC v2 signing.

Postman examples:

Collection: Integration_v2_RP_BASED

Covered requests: Create session EGN/LNC, Upload documents for signing, Validate OTP without link, Check session, Get signed documents, Close session

Open Postman collection
Expected result: signed documents or digests in the OTC v2 process.
▸ Electronic identification through B-Trust Mobile

Use when: the relying party wants to request electronic identification of a natural person through B-Trust Mobile.

Do not use when: for web onboarding with video identification, use the web identification scenario.

# Step Operation Role in the integration
1 Create request POST /signing-api/v2/identification
identificationUsingPOST		 Starts electronic identification of a natural person through B-Trust Mobile.
2 Check/result GET /signing-api/v2/identification/{callbackId}
getIdentificationResultUsingGET		 Checks status and receives the electronic identification result by callbackId.
3 Access settings POST /signing-api/v2/identification/accessSettings
createIdentificationRequestDataAccessSettingsUsingPOST		 Creates data access settings for an identification request.
Expected result: you receive a status and, upon successful completion, identification data according to the agreed scope.
▸ Web identification

Use when: the user goes through a web identification process — data check, document check, liveness/selfie and result retrieval.

Do not use when: for an already registered B-Trust Mobile user if the scenario is only eID through the app.

# Step Operation Role in the integration
1 Start web identification POST /signing-api/v2/identification/web/websession/start
startWebIdentificationUsingPOST		 Starts a web identification session with the option of a subsequent OTC process.
2 Start without OTC POST /signing-api/v2/identification/web/websession/without-otc/start
startWebIdentificationWithoutOtcUsingPOST		 Starts a web identification session without an OTC process.
3 Check status GET /signing-api/v2/identification/web/{resultId}/status
getWebIdentificationStatusUsingGET		 Returns the current status and step of a web identification request.
4 Get result GET /signing-api/v2/identification/web/{resultId}/result/{processState}/{sessionId}/{onlyMetadata}
getWebIdentificationResultsUsingGET		 Returns the result of a successfully completed web identification.

Postman examples:

Collection: Integration WEB

Covered requests: Start web identification session, Check web identification status, Generate OTP, Validate OTP, Get web identification result

Open Postman collection
Expected result: you receive the identification result and, where applicable, data for subsequent signing.
▸ Web identification + signing with one-time QES

Use when: after successful web identification, the user must sign documents with OTC.

Do not use when: if the process is identification only, without signing.

# Step Operation Role in the integration
1 Create sign session POST /signing-api/v2/identification/web/websession/create/signsession
createSignSessionUsingPOST_1		 Creates a sign session request after web identification.
2 Start sign session POST /signing-api/v2/identification/web/signsession/start
startSignSessionUsingPOST		 Starts a document signing session after web identification.
3 Generate OTP GET /signing-api/v2/identification/web/generate/otp/{resultId}
generateOtpCodeForOtcUsingGET		 Generates an OTP code for a one-time certificate and sends an SMS.
4 Validate OTP POST /signing-api/v2/identification/web/validate/otp
validateOtpCodeForOtcUsingPOST		 Validates an OTP code for a one-time certificate.

Postman examples:

Collection: Integration WEB

Covered requests: Start web identification session, Start sign session, Generate OTP, Validate OTP, Revoke web sign session

Open Postman collection
Expected result: after identification, signing is started, the user confirms with OTP, and the result is returned through callback/status.
▸ Automated/server-side signing

Use when: the organization needs automated signing without each operation being confirmed by the user in B-Trust Mobile.

Do not use when: for ordinary user signing; consent/accessToken is required first.

# Step Operation Role in the integration
1 Create consent POST /signing-api/v2/arsign/consent
sendConsentRequestUsingPOST		 Sends a consent request for automated/server-side signing.
2 Get consent GET /signing-api/v2/arsign/consent/{callbackId}
getConsentUsingGET		 Receives the result of the consent request, including accessToken and signed consent.
3 Check accessToken GET /signing-api/v2/arsign/validate/token
validateAccessTokenUsingGET		 Checks the validity/expiration of accessToken.
4 Synchronous signing POST /signing-api/v2/arsign/sync
sendSyncSignRequestUsingPOST		 Executes a synchronous automated signing request with accessToken.
5 Asynchronous batch signing POST /signing-api/v2/arsign/batch/async/sign
sendAsyncSignInBatchRequestUsingPOST		 Creates an asynchronous request for batch automated signing.
6 Batch result GET /signing-api/v2/arsign/batch/async/{callbackId}
getSignedBatchOrCheckSigningStatusUsingGET		 Checks status or obtains the result of asynchronous batch automated signing.

Postman examples:

Collection: Integration_Automatic Remote Sign

Covered requests: Send consent request, Get consent response, Validate accessToken, Send synchronous ARS request, Get document by signatureID

Open Postman collection
Expected result: after confirmed consent, the system signs automatically through accessToken.
▸ OIDC signing

Use when: the integration follows an OpenID Connect-based flow for signing and obtaining a result/user data.

Do not use when: does not replace the standard Signing API flow when the process is a classic server-to-server integration.

# Step Operation Role in the integration
1 Initiate OIDC request POST /signing-api/v2/oidc/sign
signUsingPOST		 Initiates an OIDC signing request.
2 Get result GET /signing-api/v2/oidc/sign/result/{callbackId}
getSignResultUsingGET		 Receives the result of an OIDC signing request by callbackId.
3 Get user data GET /signing-api/v2/oidc/sign/result/user-data/{callbackId}
getSignResultUserDataUsingGET		 Receives the user data related to a successfully completed OIDC request.
Expected result: you receive the OIDC signing result and, upon successful completion, related user data.

POSTMAN COLLECTIONS

The Postman collections are mapped to the specific scenarios above. This section is a general index for quick access to the available collections.

Postman collection Main purpose Link
Integration WEB Web identification, web sign session, OTP generation/validation and result. Open
Integration_v2_RP_BASED OTC v2 / RP based flow: create session, upload documents, OTP, check session, get signed documents, close session. Open
Integration Automatic Remote Sign Automated signing: consent, accessToken validation, synchronous signing, get signed document. Open
Parcel_Integration Parcels: check client, send parcel sign request, parcel details, download signed parcel, reject parcel. Open

Additional services and components

This section brings together services and technical components that can be used independently or as part of the main integration scenarios above. They support processes such as time-stamping, signed document validation, strong customer authentication, local signing and on-premise integrations.

Section structure: first, a short orientation explains when each service is used, while technical URLs, documents, installation files and supporting materials are grouped by service in the expandable sections below.
Group Services / components When they are used
Trust services APIs Time Stamp
Validation of electronically signed documents		 When the system needs to add evidentiary time or validate electronically signed documents before acceptance, processing or archiving.
Authentication and confirmation B-Token When the organization wants to confirm actions, login or transactions through B-Trust Mobile.
Client-side and on-premise components BISS
BSecure DSS Lite
BSecure DSS		 When signing is performed with a local certificate, smart card, HSM or the organization’s internal infrastructure.
▸ Trust services APIs

Use when: the integration needs to add evidentiary time or validate electronically signed documents as part of a business process, inbound document flow, archive or automatic processing.

Access: the services are used from pre-authorized addresses or through a username and password provided by BORICA.

Time-stamping / Time Stamp

Issues a time stamp for an electronic document, signature, transaction or other electronic content. It is suitable for proving the time at which data existed and for processes requiring traceability over time.

Validation of electronically signed documents

API service for validating electronically signed documents. It is suitable for incoming signed files, automatic processing, checks before archiving and validation of signed results from external processes.

Expected result: the integrator can clearly choose between the time-stamping service and the validation service, with separate URLs and documents for each.
▸ Authentication and confirmation through B-Token

Use when: the user needs to confirm an action, login, transaction or another business process through B-Trust Mobile.

B-Token

Component for strong customer authentication through B-Trust Mobile. It is suitable for confirming actions, authorizing transactions, logging into systems or adding protection to customer processes.

Test Swagger https://cqes-rpuat.b-trust.bg/sca-adapter-external/swagger-ui.html
Production API URL https://cqes-rp.b-trust.bg/sca-adapter-external
Documentation Integration document: coming soon.
Expected result: the integrator can use B-Trust Mobile as a strong confirmation channel for actions in its own system.
▸ Client-side and on-premise components

Use when: signing is performed with a local certificate, smart card, HSM or the organization’s internal infrastructure instead of through a cloud user process.

Browser Independent Signing Service / BISS

Client component for local signing without dependency on a specific browser. It is used when signing with a certificate on a smart card or another local carrier.

BSecure DSS Lite

On-premise solution for extending an already created digital signature to standardized electronic signing formats. It supports scenarios with BISS, Time Stamp, OCSP/CRL and CAdES, PAdES and XAdES formats.

BSecure DSS

Full on-premise solution for automating processes with a large number of electronic documents. It works with advanced certificates in a file (PFX) or qualified QES certificates on a smart card or HSM.

Expected result: the integrator can choose the appropriate client-side or on-premise component depending on the signing method — locally through BISS, by extending a signature with BSecure DSS Lite, or through a broader mass-processing solution with BSecure DSS.

Compact operation index

The index is reference-oriented and intentionally more compact than the scenario section. It shows only the endpoint, operationId and a short human-readable description. For parameters, models, sample payloads and response codes, use Swagger.

Note: Not every operation is intended for every integrator. Access is granted only for the agreed and technically enabled operations.
▸ Signing API — core signing and parcels (13 operations)
Endpoint operationId Human-readable description
POST /signing-api/v2/auth clientAuthUsingPOST Issues a client token for a user based on profileId and OTP/authorization code.
GET /signing-api/v2/cert/{profileId} getCertUsingGET Returns the client’s X.509 certificate by profileId.
GET /signing-api/v2/cert/identity/{identificatorType}/{identityValue} getCertByPersonalIdUsingGET Returns the client’s X.509 certificate by identifier type and value.
GET /signing-api/v2/rpcallbackid/{rpCallbackId} getSignedResultByRpCallbackIdUsingGET Checks a signing result by the relying party callback identifier.
POST /signing-api/v2/sign sendSignRequestUsingPOST Creates a signing request for a document/file to a B-Trust Mobile user.
GET /signing-api/v2/sign/{callbackId} getSignedResultUsingGET Checks the status/result of a signing request by callbackId.
GET /signing-api/v2/sign/checkclient getCustomerWithActiveCQESUsingGET Checks whether a client has an active cloud qualified electronic signature.
GET /signing-api/v2/sign/content/{id} getSignedContentUsingGET Downloads a signed document by content identifier.
GET /signing-api/v2/sign/evidence/receipt getEvidencePDFUsingGET Downloads PDF evidence/receipt for the specified messageIdentifier.
POST /signing-api/v2/sign/parcel sendParcelSignRequestUsingPOST Creates a request for signing a document package/parcel.
GET /signing-api/v2/sign/parcel/details/{uuid} getParcelDetailsShortUsingGET Returns short parcel data by uuid.
GET /signing-api/v2/sign/parcel/download getSignedParcelDocumentsUsingGET Downloads the signed documents from a parcel.
POST /signing-api/v2/signviaqr sendSignRequestViaQRUsingPOST Creates a signing request via QR code.
▸ Signing API — OTC signing and issue-and-sign (7 operations)
Endpoint operationId Human-readable description
POST /signing-api/v2/otc/sign signOtcDocumentsUsingPOST Starts signing with a one-time cloud qualified electronic signature.
GET /signing-api/v2/otc/content/{id} getOTCSignedContentUsingGET Downloads signed content after OTC signing.
POST /signing-api/v2/otc/archive archiveOtcDocumentsUsingPOST Archives documents signed with OTC.
POST /signing-api/v2/otc/issueAndSign/startSession createOTCIssueRequestUsingPOST_1 Creates an OTC issue-and-sign session.
PUT /signing-api/v2/otc/issueAndSign/signDocs sendDocsForSigningUsingPUT Uploads documents to the OTC session.
POST /signing-api/v2/otc/issueAndSign/validateOTP validateOTPCodeUsingPOST Validates OTP and finalizes the OTC process.
GET /signing-api/v2/otc/issueAndSign/getSignedDocs getSignedDocumentsUsingGET Downloads documents after OTC signing.
▸ Automatic Remote Signing API (6 operations)
Endpoint operationId Human-readable description
POST /signing-api/v2/arsign/consent sendConsentRequestUsingPOST Sends a consent request for automated signing.
GET /signing-api/v2/arsign/consent/{callbackId} getConsentUsingGET Receives the result of the consent request.
GET /signing-api/v2/arsign/validate/token validateAccessTokenUsingGET Checks accessToken.
POST /signing-api/v2/arsign/sync sendSyncSignRequestUsingPOST Executes synchronous automated signing.
POST /signing-api/v2/arsign/batch/async/sign sendAsyncSignInBatchRequestUsingPOST Creates an asynchronous batch request.
GET /signing-api/v2/arsign/batch/async/{callbackId} getSignedBatchOrCheckSigningStatusUsingGET Checks status or receives a batch result.
▸ Remote Identification API (8 operations)
Endpoint operationId Human-readable description
POST /signing-api/v2/identification identificationUsingPOST Starts electronic identification through B-Trust Mobile.
GET /signing-api/v2/identification/{callbackId} getIdentificationResultUsingGET Receives the electronic identification result.
POST /signing-api/v2/identification/web/websession/start startWebIdentificationUsingPOST Starts a web identification session.
POST /signing-api/v2/identification/web/websession/without-otc/start startWebIdentificationWithoutOtcUsingPOST Starts web identification without OTC.
GET /signing-api/v2/identification/web/{resultId}/status getWebIdentificationStatusUsingGET Returns web identification status.
GET /signing-api/v2/identification/web/{resultId}/result/{processState}/{sessionId}/{onlyMetadata} getWebIdentificationResultsUsingGET Returns the web identification result.
GET /signing-api/v2/identification/web/generate/otp/{resultId} generateOtpCodeForOtcUsingGET Generates OTP for OTC.
POST /signing-api/v2/identification/web/validate/otp validateOtpCodeForOtcUsingPOST Validates OTP for OTC.
▸ OIDC API (3 operations)
Endpoint operationId Human-readable description
POST /signing-api/v2/oidc/sign signUsingPOST Initiates an OIDC signing request.
GET /signing-api/v2/oidc/sign/result/{callbackId} getSignResultUsingGET Receives the OIDC signing result.
GET /signing-api/v2/oidc/sign/result/user-data/{callbackId} getSignResultUserDataUsingGET Receives user data from the OIDC flow.

Requesting access

To execute active operations through the API, access must be requested and enabled in advance for the relying party. For this purpose, the integrator/client completes a registration form and sends it to BORICA for processing.

What is requested

the services and API groups to be used;
test and/or production environment;
relying party details;
technical contact for the integration;
SSL client certificate for active operations;
callback URLs for asynchronous results.

What BORICA provides

relyingPartyId for the relying party;
enabled access to the agreed services;
confirmation of registered SSL certificate;
guidelines for test scenarios and transition to production.
Registration form: Complete the form for access to BORICA trust services and send it to support@borica.bg.
Download registration form Send inquiry

Testing and production readiness

This section is not a standalone technical specification; it is a short checklist before moving to production. Its purpose is to avoid the most common integration issues.

Check Why it matters
Successful process The integrator must be able to create a request, receive a successful status and download the result.
Rejected or expired process The system must handle user rejection, request expiration and unsuccessful processes without blocking the customer flow.
Callback and status check The callback URL must be accessible, and where necessary the system must be able to check status through the API.
Result download After a successful final status, the signed documents, report, evidence or identification result must be downloaded according to the service.
Access and security The registered SSL certificate, valid relyingPartyId, service permissions and correct logging of callbackId/rpCallbackId are verified.

Contacts

For access requests, integration questions, test environment or clarifications regarding the API documentation, please contact the BORICA support team.

E-mail: support@borica.bg

When sending a request, it is recommended to specify the organization, contact person, desired service/API group, access environment and a short description of the integration scenario.

Frequently asked questions

▸ Why are not all parameters of each operation described?
To avoid duplicating Swagger. This page shows when and why a given operation is used. Full parameters, models, sample values and response codes remain in Swagger.
▸ Which operation should I use for standard document signing?
The usual flow is sendSignRequestUsingPOST to create a request, getSignedResultUsingGET or getSignedResultByRpCallbackIdUsingGET for status, and getSignedContentUsingGET to download the signed document.
▸ What is the difference between standard and automated signing?
With standard signing, the user confirms each request in B-Trust Mobile. With automated signing, consent is first created and signed, producing an accessToken; after that, the system can perform synchronous or asynchronous signing operations without confirmation for each individual operation.
▸ When should I use Remote Identification API?
When the process requires electronic identification of a natural person — through B-Trust Mobile or through a web identification process. If one-time signing is required after identification, use the “Web identification + OTC signing” scenario.

Back to top