English
Borica logo B-Trust logo B-trust Moble Efactura logo
Search icon
Header clients image
Начало > Услуги

Услуги

За разработчици

Съдържание

Как да започнете Искам да... Общи понятия
Сценарии и операции Компактен индекс на операциите Swagger връзки
Заявяване на достъп Тестове и продукционна готовност Контакти
Postman collections Допълнителни услуги Често задавани въпроси

Как да започнете

1. Изберете сценарий от секцията „Искам да...“.
2. Прегледайте процеса — кои стъпки се изпълняват и кои операции участват.
3. Отворете съответния Swagger за точните параметри, request/response модели и кодове за отговор.
4. Заявете достъп до тестова среда и необходимите операции.
5. Регистрирайте SSL сертификат и използвайте предоставения relyingPartyId за активни заявки.
6. Тествайте успешни и отказани сценарии преди преминаване към продукционна среда.

Искам да...

Този раздел е бърз вход към документацията според задачата на разработчика. Всяка карта показва подходящия сценарий, основния API и ключовите операции, които участват. Подробните параметри остават в Swagger.

Да проверя дали клиентът има активен облачен КЕП

Използва се преди подписване, когато трябва да установите дали клиентът има профил/сертификат и как да бъде адресиран.

API: Signing API

Основни операции: checkclient, getCert, clientAuth

  
Да изпратя документ за подписване през B-Trust Mobile

Стандартният сценарий за подписване на PDF, договор, заявление или друг документ от конкретен потребител.

API: Signing API

Основни операции: sendSignRequest, getSignedResult, getSignedContent
Да реализирам подписване чрез QR код

Подходящо когато потребителят сканира QR код с B-Trust Mobile и сам избира удостоверение за подписване.

API: Signing API

Основни операции: sendSignRequestViaQR, getSignedResult, getSignedContent

  
Да подпиша пакет от документи

Използва се когато няколко документа трябва да бъдат обработени като една пратка/общ процес.

API: Signing API

Основни операции: sendParcelSignRequest, getParcelDetails, download parcel
Да проследя доставка/връчване на документ

Операции около преглед, статус, получени пратки и доказателство/разписка за доставка.

API: Signing API

Основни операции: received-parcel-usage, parcel/viewed, evidence/receipt

  
Да подпиша с еднократен облачен КЕП

OTC сценарий за еднократно подписване на документи без стандартна употреба на B-Trust Mobile като постоянен канал.

API: Signing API / OTC

Основни операции: otc/sign, otc/content, otc/archive
Да идентифицирам потребител дистанционно

Web идентификация или идентификация през B-Trust Mobile, според избрания процес и канал.

API: Remote Identification API

Основни операции: identification, websession/start, status/result

  
Да направя web идентификация и после OTC подписване

Цялостен поток за идентификация, създаване на sign session, OTP потвърждение и подписване.

API: Remote Identification API / OTC

Основни операции: create sign session, generate OTP, validate OTP
Да реализирам автоматизирано/сървърно подписване

За процеси с предварително съгласие, accessToken и подписване без отделно потребителско потвърждение за всяка операция.

API: Automatic Remote Signing API

Основни операции: consent, arsign/sync, batch/async

  
Да използвам OIDC базиран процес за подписване

OIDC сценарий за заявка за подписване, получаване на резултат и потребителски данни.

API: OIDC API

Основни операции: oidc/sign, sign/result, user-data

Общи понятия

Понятие Значение за интеграцията
relyingPartyId Идентификатор на доверяващата се страна. Използва се при активни API операции и се предоставя от БОРИКА.
rpToClientAuthorization Header, чрез който доверяващата се страна посочва как се идентифицира клиентът — например personalId, certId, profileId или clientToken.
callbackId Идентификатор на заявка, върнат от API. Използва се за проверка на статус, получаване на резултат или изтегляне на съдържание.
rpCallbackId Идентификатор, зададен от доверяващата се страна. Използва се когато клиентската система иска сама да управлява корелацията на процеса.
OTC Еднократен облачен квалифициран електронен подпис/сертификат, използван за конкретен процес или подписване.
Callback / Pull При асинхронни процеси резултатът може да се получи чрез callback към доверяващата се страна или чрез операция за проверка на статус.

Сценарии и операции

Тези секции отговарят на въпроса „Какво точно трябва да извикам, за да реализирам дадена функционалност?“. Те съдържат само операционната последователност и предназначението на всяка операция.

▸ Проверка на потребител и избор на идентификатор

Използвайте когато: трябва да установите дали потребителят има активен облачен КЕП, кое удостоверение да използвате или как да го адресирате в следваща заявка.

Не използвайте когато: това не е самостоятелна услуга за подписване; използва се като подготовка преди подписване, автентикация или автоматизирано подписване.

# Стъпка Операция Роля в интеграцията
1 Проверка за активен облачен КЕП GET /signing-api/v2/sign/checkclient
getCustomerWithActiveCQESUsingGET		 Проверява дали клиент има активен облачен квалифициран електронен подпис.
2 Получаване на сертификат по profileId GET /signing-api/v2/cert/{profileId}
getCertUsingGET		 Връща X.509 сертификат на клиент по profileId.
3 Получаване на сертификат по идентификатор GET /signing-api/v2/cert/identity/{identificatorType}/{identityValue}
getCertByPersonalIdUsingGET		 Връща X.509 сертификат на клиент по тип идентификатор и стойност.
4 Получаване на client token POST /signing-api/v2/auth
clientAuthUsingPOST		 Издава client token за потребител на база profileId и OTP/authorization code.
Очакван резултат: избирате устойчив начин за адресиране на клиента: personalId, certId, profileId или clientToken.
▸ Подписване на единичен документ през B-Trust Mobile

Използвайте когато: потребителят трябва да получи документ в B-Trust Mobile, да го подпише или откаже, а системата на доверяващата се страна да получи подписания резултат.

Не използвайте когато: за QR подписване, пакет документи или автоматизирано подписване без потребителско потвърждение използвайте съответните отделни сценарии.

# Стъпка Операция Роля в интеграцията
1 Създаване на заявка POST /signing-api/v2/sign
sendSignRequestUsingPOST		 Създава заявка за подписване на документ/файл към потребител на B-Trust Mobile.
2 Проверка по callbackId GET /signing-api/v2/sign/{callbackId}
getSignedResultUsingGET		 Проверява статус/резултат от заявка за подписване по callbackId.
3 Проверка по rpCallbackId GET /signing-api/v2/rpcallbackid/{rpCallbackId}
getSignedResultByRpCallbackIdUsingGET		 Проверява резултат от подписване по callback идентификатор на доверяващата се страна.
4 Изтегляне на подписан документ GET /signing-api/v2/sign/content/{id}
getSignedContentUsingGET		 Изтегля подписан документ по идентификатор на съдържанието.
Очакван резултат: при успешен статус получавате идентификатор на подписаното съдържание и изтегляте подписания файл.
▸ Подписване чрез QR код

Използвайте когато: потребителят сканира QR код с B-Trust Mobile и избира удостоверение за подписване.

Не използвайте когато: не е подходящо, ако процесът трябва да бъде насочен автоматично към конкретен потребител без сканиране.

# Стъпка Операция Роля в интеграцията
1 Създаване на QR заявка POST /signing-api/v2/signviaqr
sendSignRequestViaQRUsingPOST		 Създава заявка за подписване чрез QR код за сканиране с B-Trust Mobile.
2 Проверка на статус/резултат GET /signing-api/v2/sign/{callbackId}
getSignedResultUsingGET		 Проверява статус/резултат от заявка за подписване по callbackId.
3 Изтегляне на подписан документ GET /signing-api/v2/sign/content/{id}
getSignedContentUsingGET		 Изтегля подписан документ по идентификатор на съдържанието.
Очакван резултат: получавате QR код и callbackId. След сканиране и подписване изтегляте подписания документ.
▸ Подписване на пакет/пратка от документи

Използвайте когато: няколко документа трябва да бъдат обработени като един общ процес — например комплект договори, заявления или документи за клиентско досие.

Не използвайте когато: за единичен документ, ако няма нужда от групиране, общ статус или изтегляне на пакет.

# Стъпка Операция Роля в интеграцията
1 Създаване на заявка за пратка POST /signing-api/v2/sign/parcel
sendParcelSignRequestUsingPOST		 Създава заявка за подписване на пакет/пратка от документи.
2 Обвързване с удостоверение POST /signing-api/v2/sign/bindSignRequest/parcel/
bindParcelSignRequestUsingPOST		 Обвързва заявка за подписване на пратка с избрано удостоверение.
3 Проверка на детайли GET /signing-api/v2/sign/parcel/details/{uuid}
getParcelDetailsShortUsingGET		 Връща кратки данни за пратка по uuid.
4 Изтегляне на подписани документи GET /signing-api/v2/sign/parcel/download
getSignedParcelDocumentsUsingGET		 Изтегля подписаните документи от пратка.
5 Отказ на пратка POST /signing-api/v2/sign/parcel/reject
rejectParcelSignRequestUsingPOST		 Отказва заявка за подписване на пратка.

Postman примери:

Колекция: Parcel_Integration

Покрити заявки: Check client, Send parcel sign request, Get parcel details, Download signed parcel, Reject parcel sign request

Отвори Postman collection
Очакван резултат: получавате подписани документи поотделно или като пакет, според резултата от операцията.
▸ Връчване, доставка и доказателства

Използвайте когато: трябва да проследите получена пратка, да маркирате преглед или да изтеглите доказателство/разписка.

Не използвайте когато: не замества самото подписване; това са операции около жизнения цикъл на пратка/доставка.

# Стъпка Операция Роля в интеграцията
1 Списък с получени пратки GET /signing-api/v2/received-parcel-usage/list
getReceivedParcelUsageContentUsingGET		 Връща списък с получени пратки/usage съдържание и статуси.
2 Маркиране като прегледано POST /signing-api/v2/sign/parcel/viewed
changeStatusToViewedUsingPOST		 Маркира регистрирана поща/пратка като прегледана.
3 Изтегляне на доказателство GET /signing-api/v2/sign/evidence/receipt
getEvidencePDFUsingGET		 Изтегля PDF доказателство/разписка за посочен messageIdentifier.
Очакван резултат: получавате статуси, информация за употреба и доказателствен документ за доставката/връчването.
▸ Еднократен ОКЕП за подписване, когато данните/сесията са подготвени

Използвайте когато: трябва да изпратите документи за подписване с еднократен облачен квалифициран електронен подпис и да изтеглите резултата.

Не използвайте когато: не покрива цял web идентификационен процес; за него използвайте сценария за web идентификация + OTC.

# Стъпка Операция Роля в интеграцията
1 Стартиране на OTC подписване POST /signing-api/v2/otc/sign
signOtcDocumentsUsingPOST		 Стартира подписване на документи с еднократен облачен квалифициран електронен подпис.
2 Изтегляне на подписано съдържание GET /signing-api/v2/otc/content/{id}
getOTCSignedContentUsingGET		 Изтегля подписано съдържание по идентификатор, получен след OTC подписване.
3 Архивиране на OTC документи POST /signing-api/v2/otc/archive
archiveOtcDocumentsUsingPOST		 Архивира подписани с OTC документи в услугата за дългосрочно съхранение.
Очакван резултат: получавате подписано съдържание от OTC процеса и при нужда го архивирате.
▸ Еднократен ОКЕП — издаване и подписване в една сесия

Използвайте когато: процесът включва валидиране на лични данни, създаване на сесия, качване на документи, OTP потвърждение и изтегляне на подписаните документи.

Не използвайте когато: ако идентификацията се прави през web flow от Remote Identification API, вижте сценария „Web идентификация + OTC“.

# Стъпка Операция Роля в интеграцията
1 Създаване на OTC сесия POST /signing-api/v2/otc/issueAndSign/startSession
createOTCIssueRequestUsingPOST_1		 Валидира личните данни и създава OTC issue-and-sign сесия.
2 Проверка на сесия GET /signing-api/v2/otc/issueAndSign/checkSession
checkSessionUsingGET		 Проверява състоянието на OTC issue-and-sign сесия.
3 Качване на документи PUT /signing-api/v2/otc/issueAndSign/signDocs
sendDocsForSigningUsingPUT		 Качва документи към OTC сесията и стартира SMS/OTP потвърждение.
4 Валидиране на OTP POST /signing-api/v2/otc/issueAndSign/validateOTP
validateOTPCodeUsingPOST		 Валидира OTP кода и финализира OTC issue-and-sign процеса.
5 Изтегляне на подписани документи GET /signing-api/v2/otc/issueAndSign/getSignedDocs
getSignedDocumentsUsingGET		 Изтегля документите след подписване с OTC.
Очакван резултат: финализирана сесия с подписани документи и проследим статус.
▸ Еднократен ОКЕП v2 — документи или дайджести

Използвайте когато: трябва да работите с v2 поток за OTC, включително подаване на документи или дайджести за подписване.

Не използвайте когато: не смесвайте v1 и v2 операции в една интеграция без изрична техническа причина.

# Стъпка Операция Роля в интеграцията
1 Създаване на сесия v2 POST /signing-api/v2/otc/issueAndSign/v2/createSession
createOTCIssueRequestUsingPOST		 Валидира лични данни и създава OTC issue-and-sign сесия v2.
2 Издаване на OTC чрез OTP POST /signing-api/v2/otc/issueAndSign/v2/issueOTC
issueOTCCertificateUsingPOST		 Изпраща OTP за стартиране на процеса по издаване на OTC.
3 Получаване на издаден OTC GET /signing-api/v2/otc/issueAndSign/v2/certificate
getOTCCertificateUsingGET		 Връща издадения еднократен сертификат.
4 Качване на документи/дайджести PUT /signing-api/v2/otc/issueAndSign/v2/sendDocs
sendDocsDigestForSigningUsingPUT		 Качва документи или дайджести за подписване в OTC v2 процес.
5 Изтегляне на подписани документи/дайджести GET /signing-api/v2/otc/issueAndSign/v2/getSignedDocs
getSignedDocumentsDigestUsingGET		 Изтегля подписаните документи/дайджести след OTC v2 подписване.

Postman примери:

Колекция: Integration_v2_RP_BASED

Покрити заявки: Create session EGN/LNC, Upload documents for signing, Validate OTP without link, Check session, Get signed documents, Close session

Отвори Postman collection
Очакван резултат: подписани документи или дайджести в v2 OTC процес.
▸ Електронна идентификация чрез B-Trust Mobile

Използвайте когато: доверяващата се страна иска да заяви електронна идентификация на физическо лице чрез B-Trust Mobile.

Не използвайте когато: за web onboarding с видео идентификация използвайте web identification сценария.

# Стъпка Операция Роля в интеграцията
1 Създаване на заявка POST /signing-api/v2/identification
identificationUsingPOST		 Стартира електронна идентификация на физическо лице чрез B-Trust Mobile.
2 Проверка/резултат GET /signing-api/v2/identification/{callbackId}
getIdentificationResultUsingGET		 Проверява статус и получава резултат от електронна идентификация по callbackId.
3 Настройки за достъп POST /signing-api/v2/identification/accessSettings
createIdentificationRequestDataAccessSettingsUsingPOST		 Създава настройки за достъп до данни при заявка за идентификация.
Очакван резултат: получавате статус и при успешно приключване — идентификационни данни според договорения обхват.
▸ Web идентификация

Използвайте когато: потребителят преминава през web идентификационен процес — проверка на данни, документ, liveness/selfie и получаване на резултат.

Не използвайте когато: за вече регистриран B-Trust Mobile потребител, ако сценарият е само eID през приложението.

# Стъпка Операция Роля в интеграцията
1 Стартиране на web идентификация POST /signing-api/v2/identification/web/websession/start
startWebIdentificationUsingPOST		 Стартира web сесия за идентификация с възможност за последващ OTC процес.
2 Стартиране без OTC POST /signing-api/v2/identification/web/websession/without-otc/start
startWebIdentificationWithoutOtcUsingPOST		 Стартира web сесия за идентификация без OTC процес.
3 Проверка на статус GET /signing-api/v2/identification/web/{resultId}/status
getWebIdentificationStatusUsingGET		 Връща текущ статус и стъпка на web идентификационна заявка.
4 Получаване на резултат GET /signing-api/v2/identification/web/{resultId}/result/{processState}/{sessionId}/{onlyMetadata}
getWebIdentificationResultsUsingGET		 Връща резултат от успешно завършена web идентификация.

Postman примери:

Колекция: Integration WEB

Покрити заявки: Start web identification session, Check web identification status, Generate OTP, Validate OTP, Get web identification result

Отвори Postman collection
Очакван резултат: получавате резултат от идентификацията и, ако е приложимо, данни за следващо подписване.
▸ Web идентификация + подписване с еднократен ОКЕП

Използвайте когато: след успешна web идентификация потребителят трябва да подпише документи с OTC.

Не използвайте когато: ако процесът е само идентификация без подписване.

# Стъпка Операция Роля в интеграцията
1 Създаване на sign session POST /signing-api/v2/identification/web/websession/create/signsession
createSignSessionUsingPOST_1		 Създава заявка за sign session след web идентификация.
2 Стартиране на sign session POST /signing-api/v2/identification/web/signsession/start
startSignSessionUsingPOST		 Стартира сесия за подписване на документи след web идентификация.
3 Генериране на OTP GET /signing-api/v2/identification/web/generate/otp/{resultId}
generateOtpCodeForOtcUsingGET		 Генерира OTP код за еднократен сертификат и изпраща SMS.
4 Валидиране на OTP POST /signing-api/v2/identification/web/validate/otp
validateOtpCodeForOtcUsingPOST		 Валидира OTP код за еднократен сертификат.

Postman примери:

Колекция: Integration WEB

Покрити заявки: Start web identification session, Start sign session, Generate OTP, Validate OTP, Revoke web sign session

Отвори Postman collection
Очакван резултат: след идентификацията се стартира подписване, потребителят потвърждава с OTP, а резултатът се връща чрез callback/status.
▸ Автоматизирано/сървърно подписване

Използвайте когато: организацията има нужда от автоматизирано подписване без всяка операция да се потвърждава от потребителя в B-Trust Mobile.

Не използвайте когато: за обикновено потребителско подписване; първо е необходимо съгласие/accessToken.

# Стъпка Операция Роля в интеграцията
1 Създаване на съгласие POST /signing-api/v2/arsign/consent
sendConsentRequestUsingPOST		 Изпраща заявка за съгласие за автоматизирано/сървърно подписване.
2 Получаване на съгласие GET /signing-api/v2/arsign/consent/{callbackId}
getConsentUsingGET		 Получава резултат от заявката за съгласие, включително accessToken и подписано съгласие.
3 Проверка на accessToken GET /signing-api/v2/arsign/validate/token
validateAccessTokenUsingGET		 Проверява валидността/изтичането на accessToken.
4 Синхронно подписване POST /signing-api/v2/arsign/sync
sendSyncSignRequestUsingPOST		 Изпълнява синхронна заявка за автоматизирано подписване с accessToken.
5 Асинхронно пакетно подписване POST /signing-api/v2/arsign/batch/async/sign
sendAsyncSignInBatchRequestUsingPOST		 Създава асинхронна заявка за пакетно автоматизирано подписване.
6 Пакетен резултат GET /signing-api/v2/arsign/batch/async/{callbackId}
getSignedBatchOrCheckSigningStatusUsingGET		 Проверява статус или получава резултат от асинхронно пакетно автоматизирано подписване.

Postman примери:

Колекция: Integration_Automatic Remote Sign

Покрити заявки: Send consent request, Get consent response, Validate accessToken, Send synchronous ARS request, Get document by signatureID

Отвори Postman collection
Очакван резултат: след потвърдено съгласие системата подписва автоматизирано чрез accessToken.
▸ OIDC подписване

Използвайте когато: интеграцията следва OpenID Connect базиран поток за подписване и получаване на резултат/потребителски данни.

Не използвайте когато: не замества стандартния Signing API поток, ако процесът е класическа server-to-server интеграция.

# Стъпка Операция Роля в интеграцията
1 Иницииране на OIDC заявка POST /signing-api/v2/oidc/sign
signUsingPOST		 Инициира OIDC заявка за подписване.
2 Получаване на резултат GET /signing-api/v2/oidc/sign/result/{callbackId}
getSignResultUsingGET		 Получава резултат от OIDC заявка за подписване по callbackId.
3 Получаване на потребителски данни GET /signing-api/v2/oidc/sign/result/user-data/{callbackId}
getSignResultUserDataUsingGET		 Получава потребителските данни, свързани с успешно завършена OIDC заявка.
Очакван резултат: получавате резултат от OIDC подписването и при успешно приключване — свързани потребителски данни.

POSTMAN COLLECTIONS

Postman колекциите са разпределени към конкретните сценарии по-горе. Този раздел е общ индекс за бърз достъп до наличните колекции.

Postman collection Основно предназначение Линк
Integration WEB Web идентификация, web sign session, OTP генериране/валидация и резултат. Отвори
Integration_v2_RP_BASED OTC v2 / RP based flow: create session, upload documents, OTP, check session, get signed documents, close session. Отвори
Integration Automatic Remote Sign Автоматизирано подписване: consent, accessToken validation, synchronous signing, get signed document. Отвори
Parcel_Integration Пратки: check client, send parcel sign request, parcel details, download signed parcel, reject parcel. Отвори

Допълнителни услуги и компоненти

Този раздел обединява услуги и технически компоненти, които могат да се използват самостоятелно или като част от основните интеграционни сценарии по-горе. Те подпомагат процеси като удостоверяване на време, проверка на подписани документи, силна клиентска автентикация, локално подписване и on-premise интеграции.

Структура на раздела: първо е дадена кратка ориентация коя услуга кога се използва, а техническите адреси, документи, инсталационни файлове и помощни материали са групирани по услуга в разгъваемите секции по-долу.
Група Услуги / компоненти Кога се използват
Удостоверителни API услуги Time Stamp
Валидация на електронно подписани документи		 Когато системата трябва да добавя доказателствено време или да проверява електронно подписани документи преди приемане, обработка или архивиране.
Автентикация и потвърждение B-Token Когато организацията иска да потвърждава действия, вход или трансакции през B-Trust Mobile.
Клиентски и on-premise компоненти BISS
BSecure DSS Lite
BSecure DSS		 Когато подписването се извършва с локален сертификат, смарт карта, HSM или вътрешна инфраструктура на организацията.
▸ Удостоверителни API услуги

Използвайте когато: интеграцията трябва да добавя доказателствено време или да проверява електронно подписани документи като част от бизнес процес, входящ документооборот, архив или автоматична обработка.

Достъп: услугите се използват от предварително разрешени адреси или чрез потребителско име и парола, предоставени от БОРИКА.

Удостоверяване на време / Time Stamp

Издава времеви печат за електронен документ, подпис, трансакция или друго електронно съдържание. Подходящо е при доказване на момент на съществуване на данни и при процеси, изискващи проследимост във времето.

Валидация на електронно подписани документи

API услуга за проверка на електронно подписани документи. Подходяща е за входящи подписани файлове, автоматична обработка, контрол преди архивиране и валидация на подписани резултати от външни процеси.

Очакван резултат: интеграторът може ясно да избере между услуга за времеви печат и услуга за валидация, като разполага с отделни адреси и документи за всяка от тях.
▸ Автентикация и потвърждение с B-Token

Използвайте когато: потребителят трябва да потвърди действие, вход, трансакция или друг бизнес процес с неквалифицирана услуга през B-Trust Mobile.

B-Token

Компонент за силна клиентска автентикация през B-Trust Mobile. Подходящ е за потвърждение на действия, авторизация на трансакции, вход в системи или допълнителна защита на клиентски процеси.

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
Документация Интеграционен документ: очаквайте скоро.
Очакван резултат: интеграторът може да използва B-Trust Mobile като канал за силно потвърждение на действия в собствена система.
▸ Клиентски и on-premise компоненти

Използвайте когато: подписването се извършва с локално удостоверение, смарт карта, HSM или вътрешна инфраструктура на организацията, вместо чрез облачен потребителски процес.

Browser Independent Signing Service / BISS

Клиентски компонент за локално подписване без зависимост от конкретен браузър. Използва се при подписване със сертификат на смарт карта или друг локален носител.

BSecure DSS Lite

On-premise решение за разширяване на вече създаден цифров подпис до стандартизирани формати за електронно подписване. Поддържа сценарии с BISS, Time Stamp, OCSP/CRL и формати CAdES, PAdES и XAdES.

BSecure DSS

Цялостно on-premise решение за автоматизиране на процеси с голям брой електронни документи. Работи с усъвършенствани удостоверения във файл (PFX) или квалифицирани удостоверения за КЕП на смарт карта или HSM.

Очакван резултат: интеграторът може да избере подходящ клиентски или on-premise компонент според начина на подписване — локално през BISS, чрез разширяване на подпис с BSecure DSS Lite или чрез по-цялостно решение за масова обработка с BSecure DSS.

Компактен индекс на операциите

Индексът е справочен и умишлено е по-компактен от сценарийната част. Тук са показани само endpoint, operationId и кратко човешко описание. За параметри, модели, примерни payload-и и кодове за отговор използвайте Swagger.

Забележка: Не всяка операция е предназначена за всеки интегратор. Достъпът се предоставя само за договорените и технически активирани операции.
▸ Signing API — основно подписване и пратки (13 операции)
Endpoint operationId Човешко описание
POST /signing-api/v2/auth clientAuthUsingPOST Издава client token за потребител на база profileId и OTP/authorization code.
GET /signing-api/v2/cert/{profileId} getCertUsingGET Връща X.509 сертификат на клиент по profileId.
GET /signing-api/v2/cert/identity/{identificatorType}/{identityValue} getCertByPersonalIdUsingGET Връща X.509 сертификат на клиент по тип идентификатор и стойност.
GET /signing-api/v2/rpcallbackid/{rpCallbackId} getSignedResultByRpCallbackIdUsingGET Проверява резултат от подписване по callback идентификатор на доверяващата се страна.
POST /signing-api/v2/sign sendSignRequestUsingPOST Създава заявка за подписване на документ/файл към потребител на B-Trust Mobile.
GET /signing-api/v2/sign/{callbackId} getSignedResultUsingGET Проверява статус/резултат от заявка за подписване по callbackId.
GET /signing-api/v2/sign/checkclient getCustomerWithActiveCQESUsingGET Проверява дали клиент има активен облачен квалифициран електронен подпис.
GET /signing-api/v2/sign/content/{id} getSignedContentUsingGET Изтегля подписан документ по идентификатор на съдържанието.
GET /signing-api/v2/sign/evidence/receipt getEvidencePDFUsingGET Изтегля PDF доказателство/разписка за посочен messageIdentifier.
POST /signing-api/v2/sign/parcel sendParcelSignRequestUsingPOST Създава заявка за подписване на пакет/пратка от документи.
GET /signing-api/v2/sign/parcel/details/{uuid} getParcelDetailsShortUsingGET Връща кратки данни за пратка по uuid.
GET /signing-api/v2/sign/parcel/download getSignedParcelDocumentsUsingGET Изтегля подписаните документи от пратка.
POST /signing-api/v2/signviaqr sendSignRequestViaQRUsingPOST Създава заявка за подписване чрез QR код.
▸ Signing API — OTC подписване и issue-and-sign (7 операции)
Endpoint operationId Човешко описание
POST /signing-api/v2/otc/sign signOtcDocumentsUsingPOST Стартира подписване с еднократен облачен квалифициран електронен подпис.
GET /signing-api/v2/otc/content/{id} getOTCSignedContentUsingGET Изтегля подписано съдържание след OTC подписване.
POST /signing-api/v2/otc/archive archiveOtcDocumentsUsingPOST Архивира подписани с OTC документи.
POST /signing-api/v2/otc/issueAndSign/startSession createOTCIssueRequestUsingPOST_1 Създава OTC issue-and-sign сесия.
PUT /signing-api/v2/otc/issueAndSign/signDocs sendDocsForSigningUsingPUT Качва документи към OTC сесията.
POST /signing-api/v2/otc/issueAndSign/validateOTP validateOTPCodeUsingPOST Валидира OTP и финализира OTC процеса.
GET /signing-api/v2/otc/issueAndSign/getSignedDocs getSignedDocumentsUsingGET Изтегля документи след OTC подписване.
▸ Automatic Remote Signing API (6 операции)
Endpoint operationId Човешко описание
POST /signing-api/v2/arsign/consent sendConsentRequestUsingPOST Изпраща заявка за съгласие за автоматизирано подписване.
GET /signing-api/v2/arsign/consent/{callbackId} getConsentUsingGET Получава резултат от заявката за съгласие.
GET /signing-api/v2/arsign/validate/token validateAccessTokenUsingGET Проверява accessToken.
POST /signing-api/v2/arsign/sync sendSyncSignRequestUsingPOST Изпълнява синхронно автоматизирано подписване.
POST /signing-api/v2/arsign/batch/async/sign sendAsyncSignInBatchRequestUsingPOST Създава асинхронна пакетна заявка.
GET /signing-api/v2/arsign/batch/async/{callbackId} getSignedBatchOrCheckSigningStatusUsingGET Проверява статус или получава пакетен резултат.
▸ Remote Identification API (8 операции)
Endpoint operationId Човешко описание
POST /signing-api/v2/identification identificationUsingPOST Стартира електронна идентификация чрез B-Trust Mobile.
GET /signing-api/v2/identification/{callbackId} getIdentificationResultUsingGET Получава резултат от електронна идентификация.
POST /signing-api/v2/identification/web/websession/start startWebIdentificationUsingPOST Стартира web идентификационна сесия.
POST /signing-api/v2/identification/web/websession/without-otc/start startWebIdentificationWithoutOtcUsingPOST Стартира web идентификация без OTC.
GET /signing-api/v2/identification/web/{resultId}/status getWebIdentificationStatusUsingGET Връща статус на web идентификация.
GET /signing-api/v2/identification/web/{resultId}/result/{processState}/{sessionId}/{onlyMetadata} getWebIdentificationResultsUsingGET Връща резултат от web идентификация.
GET /signing-api/v2/identification/web/generate/otp/{resultId} generateOtpCodeForOtcUsingGET Генерира OTP за OTC.
POST /signing-api/v2/identification/web/validate/otp validateOtpCodeForOtcUsingPOST Валидира OTP за OTC.
▸ OIDC API (3 операции)
Endpoint operationId Човешко описание
POST /signing-api/v2/oidc/sign signUsingPOST Инициира OIDC заявка за подписване.
GET /signing-api/v2/oidc/sign/result/{callbackId} getSignResultUsingGET Получава резултат от OIDC подписване.
GET /signing-api/v2/oidc/sign/result/user-data/{callbackId} getSignResultUserDataUsingGET Получава потребителските данни от OIDC поток.

Заявяване на достъп

За изпълнение на активни операции през API е необходимо предварително да бъде заявен и активиран достъп за доверяващата се страна. За целта интеграторът/клиентът попълва регистрационна форма и я изпраща към БОРИКА за обработка.

Какво се заявява

услугите и API групите, които ще се използват;
тестова и/или продукционна среда;
данни за доверяващата се страна;
технически контакт за интеграцията;
SSL клиентски сертификат за активни операции;
callback адреси при асинхронен резултат.

Какво предоставя БОРИКА

relyingPartyId за доверяващата се страна;
активиран достъп до договорените услуги;
потвърждение за регистриран SSL сертификат;
насоки за тестови сценарии и преминаване към продукционна среда.
Регистрационна форма: Попълнете формата за достъп до удостоверителните услуги на БОРИКА и я изпратете на support@borica.bg.
Изтегли регистрационна форма Изпрати запитване

Тестове и готовност за продукционна среда

Този раздел не е самостоятелна техническа спецификация, а кратък контролен списък преди преминаване към продукционна среда. Целта е да се избегнат най-честите интеграционни проблеми.

Проверка Защо е важна
Успешен процес Интеграторът трябва да може да създаде заявка, да получи успешен статус и да изтегли резултата.
Отказан или изтекъл процес Системата трябва да обработва отказ от потребител, изтичане на заявка и неуспешен процес без блокиране на клиентския поток.
Callback и проверка на статус Callback URL трябва да е достъпен, а при нужда системата трябва да може да провери статуса чрез API.
Изтегляне на резултат След успешен финален статус трябва да се изтеглят подписани документи, отчет, доказателство или идентификационен резултат според услугата.
Достъп и сигурност Проверяват се регистриран SSL сертификат, валиден relyingPartyId, права за услугата и правилно логване на callbackId/rpCallbackId.

Контакти

За заявяване на достъп, въпроси по интеграция, тестова среда или уточнения по API документацията, моля свържете се с екипа за поддръжка на БОРИКА.

E-mail: support@borica.bg

При изпращане на заявка е препоръчително да посочите организация, лице за контакт, желана услуга/API група, среда за достъп и кратко описание на интеграционния сценарий.

Често задавани въпроси

▸ Защо не са описани всички параметри на всяка операция?
За да не се дублира Swagger. Тази страница показва кога и защо се използва дадена операция. Пълните параметри, модели, примерни стойности и кодове за отговор остават в Swagger.
▸ Коя операция да използвам за стандартно подписване на документ?
Обичайният поток е sendSignRequestUsingPOST за създаване на заявка, getSignedResultUsingGET или getSignedResultByRpCallbackIdUsingGET за статус и getSignedContentUsingGET за изтегляне на подписания документ.
▸ Каква е разликата между стандартно и автоматизирано подписване?
При стандартното подписване потребителят потвърждава всяка заявка в B-Trust Mobile. При автоматизираното подписване първо се създава и подписва съгласие, от което се получава accessToken, а след това системата може да изпълнява синхронни или асинхронни операции за подписване без потвърждение за всяка отделна операция.
▸ Кога да използвам Remote Identification API?
Когато процесът изисква електронна идентификация на физическо лице — чрез B-Trust Mobile или чрез web идентификационен процес. Ако след идентификацията трябва да има еднократно подписване, използвайте сценария „Web идентификация + OTC подписване“.

Обратно в началото