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:

  • NAME
  • ADDRESS
  • ORGANIZATION
  • EMAIL
  • VOICE

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_CARD for NAME and/or ADDRESS
  • ELECTRONIC_DOCUMENT + COMPANY_REGISTER for ORGANIZATION and/or ADDRESS
  • DATA + ADDRESS_DATABASE for ADDRESS
  • TRANSACTION + ONLINE_PAYMENT_ACCOUNT for NAME, ORGANIZATION, ADDRESS, and/or EMAIL

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 method and proof.
  • Make sure the submitted claims match 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.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.