Prepare an EPP integration by identifying the operations it performs, mapping the future behaviour and collecting evidence in the correct environment. A successful login is only one part of readiness. Renewal, transfers, notifications, error recovery and reconciliation can each fail independently of the connection itself.
This guide is a static planning resource. It does not run registry commands, collect credentials or certify an integration. Future .UK procedures remain scheduled until Nominet confirms transition; use the standardisation overview for applicability.
Inventory the integration before changing it
Start with the code and operational processes that exist. Record which application or job creates names, updates contacts, manages hosts, renews registrations, requests transfers, checks availability, reads portfolio data and consumes notifications. Include manual scripts and reporting jobs, together with their business owner.
For each dependency, record the current protocol, endpoint, authentication method, data fields and failure behaviour. Identify whether a third-party module supplies it and who is responsible for confirming support. Do not mark a dependency complete merely because a software vendor announces a future release; obtain the version, environment and test evidence applicable to your installation.
Nominet's preparation guidance identifies the technical services affected. The legacy EPP commands and Dragon EPP reference should be treated as different editions, not mixed into one command specification.
Map operations and stored data
| Area to review | Question for the integration | Evidence to retain |
|---|---|---|
| Sessions and extensions | Does login negotiate the services the application actually needs? | Environment, client version and sanitised greeting/login result |
| Registrar transfer | Have current push/handshake assumptions been separated from the scheduled pull process? | State transitions for successful, locked and invalid-code scenarios |
| Lifecycle | Does the application distinguish renewal, restoration, final deletion and relevant grace periods? | Registry response, stored state and resulting business action |
| Contact and host objects | Can the client handle object relationships and later changes without losing dependencies? | Before/after references and checks on affected domains |
| Notifications | Are messages consumed, processed and acknowledged without losing work? | Correlation reference, processing outcome and replay behaviour |
| Data retrieval | Do replacement services return all fields required by each report? | Field comparison, pagination and failure handling |
The future transfer FAQ includes the secure authorisation extension and its login declaration. Verify the complete command and extension specification rather than implementing a code field from a prose summary. The data-services guide covers RDAP and legacy-report dependencies in more detail.
Public research tools serve a different purpose from an EPP integration test. UK drop search displays a daily published schedule, and UK WHOIS lookup requests public RDAP fields directly from the browser. Do not use repeated public lookups to simulate a drop-catching system or treat a missing lookup result as acceptance of a registration request.
Authentication and certificate compatibility
Read the specific EPP certificate guidance for the intended accreditation and environment. It describes pre-sharing the public certificate and continues to state that connections without a pre-shared certificate remain limited by IP allow-listing. Supplying a certificate changes that treatment.
The same page contains forward-looking wording about removal of IP allow-listing. Do not turn that into an unsupported universal deadline or assume a legacy connection's behaviour proves the future setup. Record which mechanism your intended configuration uses and obtain clarification from Nominet where migration timing affects the plan.
For certificate-based preparation, identify who controls the private key, who can upload the public certificate, which environments and accreditations it applies to, and how rotation will be tested. Check validity and propagation/cache considerations in the current source. Store secrets in the organisation's established secure configuration, not in a test worksheet, a support screenshot or this website.
Select the correct environment
Use the environment guide before testing. The specific future .UK testbed page describes fictional fixtures and says OT&E has not yet launched at this review. A general documentation table naming OT&E is not evidence that it is available for your .UK work.
Record the endpoint in each test result. Keep configuration for current production and future testing clearly identifiable. A successful operation in a resettable test fixture is evidence about that scenario, not proof that every production domain will have the same state at transition.
Choose meaningful scenarios
Select cases from actual use and known failure risk. At a minimum, consider authentication failure; the intended create/update/renew operations; valid and expired transfer authorisation; registrar and registry locks; renewal or restoration at relevant lifecycle states; notification processing; and a successful operation whose response is not received by the client.
Test what the application does after the result, not only whether XML is accepted. For example, check that a transfer requiring a renewal creates the correct internal expectation, that a restricted action does not appear successful to support staff, and that a partial portfolio-data response does not delete unobserved local records.
Printable test-evidence table
Blank planning template, not completed test results. Use a printed copy or your organisation's existing evidence system. The “observation” and “reference” columns are deliberately left for the person performing the authorised test.
| Scenario | Environment | Expected result to define | Observation | Evidence reference |
|---|---|---|---|---|
| Login with intended authentication | Record actual test environment | Correct identity and negotiated extensions | Not yet recorded | Not yet recorded |
| Valid transfer request | Record actual test environment | Correct registrar/state and renewal handling | Not yet recorded | Not yet recorded |
| Expired TAC or blocking lock | Record actual test environment | Rejected operation, accurate customer/support state | Not yet recorded | Not yet recorded |
| Renewal or restoration | Record actual test environment | Correct expiry, grace-period and billing interpretation | Not yet recorded | Not yet recorded |
| Missing response after a mutation | Record actual test environment | Reconciliation before any unsafe duplicate action | Not yet recorded | Not yet recorded |
| Notification and duplicate delivery | Record actual test environment | Work retained and handled without duplicate effects | Not yet recorded | Not yet recorded |
| Portfolio-data retrieval fails part-way | Record actual test environment | Incomplete run identified; existing records preserved | Not yet recorded | Not yet recorded |
Include the client revision, time and source edition in the accompanying test record. Remove passwords, TACs and personal contact information from evidence that does not require them.
Failure handling and reconciliation
A connection failure after sending a command may leave its outcome unknown. Distinguish that state from a confirmed rejection. Use the registry's applicable enquiry and notification mechanisms to establish the outcome before retrying a mutation blindly. Make unresolved cases visible to the operational owner instead of recording a fabricated success or failure.
Nominet's transition guide gives specific post-transition synchronisation guidance. Plan reconciliation of local records with the registry, prioritise important cases and follow published connection and query constraints. Retain an exception list with a clear owner; do not assume changing the endpoint also makes cached data correct.
Questions to close before activation
Confirm outstanding environment access, authentication timing, vendor support, unexplained test results and the treatment of in-flight operations. The transition-check guide brings those results into an operational plan. The readiness checklist covers the wider policy and customer work that technical tests cannot settle.