API - Contact Verification flow
Contact verification information through the API
When DENIC flags a .DE holder contact for additional verification, Realtime Register notifies you through the various notifications methods: EMAIL, QUEUE, WEBHOOK. The notification tells you which contact must be verified, which claims are required, and which deadline applies.


Typical claims are:
NAMEADDRESSORGANIZATIONEMAILVOICE
In this article it is demonstrating how to do the contact verification for .DE domains, but it is a general verification flow for contacts.For the full background on DENIC NIS2, risk levels, deadlines, and consequences, see:
.DE NIS2 - Realtime Register Knowledge Base
For the latest API changes, see the API changelog:
API changelog
When do you need to act?
You need to act when you receive a DENIC data accuracy notification such as:
<code>[CONTACT VERIFICATION REQUIRED] for the following claims: [NAME, ADDRESS]

The notification may also include:
- the first domain that may be de-delegated
- the de-delegation deadline
- the first domain that may be deleted
- the deletion deadline
If the requested verification is not provided in time, DENIC may first de-delegate the domain and later delete it. Domains deleted for this reason are not restored through the normal Redemption Grace Period.
Choose the right verification method and proof
Before submitting verification information, check which combinations of method, proof, and claims are accepted.
Use the verification matrix here:
Contact verification matrix
Example combinations include:
ELECTRONIC_DOCUMENT+ID_CARDforNAMEand/orADDRESSELECTRONIC_DOCUMENT+COMPANY_REGISTERforORGANIZATIONand/orADDRESSDATA+ADDRESS_DATABASEforADDRESSTRANSACTION+ONLINE_PAYMENT_ACCOUNTforNAME,ORGANIZATION,ADDRESS, and/orEMAIL
Always make sure the claims you submit match the claims requested in the DENIC notification.
Submit verification information for an existing contact
For an existing contact, submit the verification information with the contact update endpoint:
Update Contact API documentation
Endpoint:
<code>POST /v2/customers/{customer}/contacts/{handle}/update
Example request body:
When I send a POST request to "/srs/services/customers/tester/contacts/tester/update" with the following:
"""
{
"verifications":[{
"verificationDate":"2026-04-16T00:00:00Z",
"externalId":"id_reference",
"method":"ELECTRONIC_DOCUMENT",
"proof":"ID_CARD",
"claims":[
"NAME", "ADDRESS"
]
}]
}
"""
Then the REST response code should be "200"<br>
A successful update returns either:
<code>200 OK
or, when the update is handled asynchronously:
<code>202 Accepted
Add verification information when creating a contact
If you already have valid verification evidence when creating a new contact, you can include the verifications object in the contact create request.
See:
Create Contact API documentation
Endpoint:
<code>POST /v2/customers/{customer}/contacts/{handle}
The same verifications structure can be used in the create request.
Verification fields
| Field | Description |
|---|---|
verificationDate |
Date and time when the contact was verified. Use ISO 8601 format. |
externalId |
Your own reference for the verification at the external provider or internal system. |
method |
How the verification was performed, for example ELECTRONIC_DOCUMENT, PHYSICAL_DOCUMENT, EID_AUTH, TRANSACTION, DATA, or REACHABILITY. |
proof |
The evidence used, for example ID_CARD, PASSPORT, COMPANY_REGISTER, BANK_STATEMENT, or ADDRESS_DATABASE. |
claims |
The claims covered by this verification, for example NAME, ADDRESS, ORGANIZATION, EMAIL, or VOICE. |
To use the verifications field, your API user needs the required contact verification permission.
Check whether the verification was stored
After submitting the update, retrieve the contact and check the verifications field in the response.
See:
Get Contact API documentation
Endpoint:
<code>GET /v2/customers/{customer}/contacts/{handle}
The response can include the verification information stored for the contact.
Important notes
- Submit verification information for the contact handle mentioned in the notification.
- Use the verification matrix before choosing a
methodandproof. - Make sure the submitted
claimsmatch the DENIC request. - Keep your own evidence and external reference available in case follow-up is needed.
- A successful API response confirms that the verification information was accepted by the Realtime Register API.
- Realtime Register handles the DENIC-side processing where applicable; there is no separate customer action toward DENIC after the contact update.