# ESTI / RegiX onboarding checklist
This checklist separates work that ZapaziMe can prepare from actions that must be completed by the accommodation operator or its authorized representative.
## 1. Owner/authorized-representative actions
- [ ] Confirm the legal entity or natural person operating each accommodation property.
- [ ] Record the official National Tourism Register UIN for each property.
- [ ] Create and activate an account in the official ESTI test environment: https://estitest.tourism.government.bg/
- [ ] Follow the current official RegiX consumer onboarding instructions: https://unifiedmodel.egov.bg/wps/portal/unified-model/for-developers/tech-info-for-integration/tech-info-for-integration/
- [ ] Sign in at https://info-regix.egov.bg, create the ZapaziMe consumer system, register the certificate request/CSR, then create a new access request associated with that system.
- [ ] Add and request test access to the Ministry of Tourism operation `SendInfoForAccomodationRegister` in `RegiX.MtEstiAdapter`, associate it with the certificate, and provide the requested legal basis and additional information.
- [ ] Provide the public server FQDN that will originate RegiX requests.
- [ ] Receive the test consumer OID and written confirmation of the authorized operation.
- [ ] Generate the certificate signing request on the target server; never send the private key by email or chat.
- [ ] Receive the client certificate plus the test root and intermediate certificate chain.
The application may require company identifiers, representative details and an electronic signature. It must be reviewed and submitted by an authorized person.
The old Ministry of Tourism announcement still links to `https://e-turuslugi.com/form/36/45`, but that URL no longer opens the ESTI application. Do not use it for onboarding. If the RegiX portal does not permit creation of a consumer request for this organization type, contact the official e-Government help desk at `Help@e-gov.bg` or `0700 20 341`, and ESTI support at `esti.mn@tourism.government.bg`, asking for the current procedure for an accommodation operator/PMS provider.
## 2. Infrastructure preparation
- [ ] PHP SOAP and OpenSSL extensions are enabled.
- [ ] The server clock uses NTP and the Europe/Sofia business timezone is handled correctly.
- [ ] Outbound TCP 443 is allowed to the approved RegiX test endpoint.
- [ ] The certificate chain is installed in this order: root, intermediate, client.
- [ ] The client certificate is available to PHP as a PEM containing its private key, protected with restrictive filesystem permissions.
- [ ] The certificate and password are stored outside the repository and deployment logs.
- [ ] The exact approved WSDL/endpoint is recorded; do not infer it from public production URLs.
## 3. Application configuration
Copy the ESTI block from `.env.example` and populate only the test values first. Keep:
```env
ESTI_COMMUNICATION_METHOD=csv
ESTI_REGIX_ENVIRONMENT=test
ESTI_AUTO_SUBMIT_ENABLED=false
```
until test acceptance is complete. Required test values are the accommodation UIN, approved HTTPS endpoint/WSDL, consumer OID, PEM certificate path and certificate password.
After editing environment values, run `php artisan config:clear` (or rebuild the production config cache through the normal deployment process).
## 4. Test acceptance sequence
- [ ] Configuration-status endpoint reports every test field configured.
- [ ] Connection test loads the WSDL and confirms the ESTI operation is advertised.
- [ ] A completed test stay with a Bulgarian guest is inserted.
- [ ] A completed test stay with an EU/EEA/Swiss guest is inserted.
- [ ] A completed test stay with a non-EU guest is inserted.
- [ ] The returned ESTI registration identifier is persisted for each guest.
- [ ] The same registration is updated successfully.
- [ ] The same registration is cancelled successfully.
- [ ] Duplicate insert retries do not create duplicate registrations.
- [ ] Active, future-checkout and missing-checkout stays are rejected locally.
- [ ] Rejected RegiX responses are recorded as rejected/failed, never accepted.
- [ ] Application logs contain request IDs and operational metadata, but no guest identity payloads or raw SOAP messages.
- [ ] Results are verified in the ESTI test portal.
Test-environment submissions have no legal effect. Continue using the established legal submission channel until production approval and acceptance are complete.
## 5. Production promotion
- [ ] Obtain a production OID/authorization and production client certificate.
- [ ] Configure production values separately; do not reuse the test certificate.
- [ ] Repeat insert, update and cancel smoke tests with an agreed test case.
- [ ] Enable RegiX communication only after written operational acceptance.
- [ ] Enable automatic submission only after idempotency and monitoring have been verified.
## Official references
- Ministry ESTI interface specification: https://www.tourism.government.bg/sites/tourism.government.bg/files/uploads/2019_gg/interfeysi_za_komunikaciya_s_esti.pdf
- ESTI test environment: https://estitest.tourism.government.bg/
- RegiX registry catalogue: https://info-regix.egov.bg/public/administrations/MT/registries
- Current RegiX consumer onboarding: https://unifiedmodel.egov.bg/wps/portal/unified-model/for-developers/tech-info-for-integration/tech-info-for-integration/
- RegiX certificate request guidance: https://info-regix.egov.bg/public/guides/07.03.RegixInfo.md
- RegiX certificate-chain guidance: https://info-regix.egov.bg/public/guides/08.02.RegixInfo.md