1. Read the owned domain and confirm it is active with the correct registration and expiry facts.
2. GET its certificate for the standard presentation, or POST the permitted issuer and registrant fields for your branded certificate.
3. When using your connector's own HTTPS verification page, pass its approved verify_url. The platform appends the certificate code to that page's URL.
4. Store the relevant code and certificate reference with your customer record. Display the returned html through the intended certificate/print workflow.
5. Test the verification page and confirm the facts it retrieves through the API.

A visitor follows the QR code or verification link to your public page. Your server calls the current verification API with its authorised credential and displays the returned status and facts. Keep API secrets on the server; do not embed them in a QR code, public page source or browser request.

The verification code consists of sixteen hexadecimal characters, with or without its printed dashes. The response distinguishes valid, revoked and unknown certificates. An unknown code has no verified facts. Only certificates issued by this platform can be verified through this route.

The certificate's issued_on describes the registration date being certified. The first-print timestamp is recorded separately as first_issued_at. Reprinting the same registration facts is not a new domain registration.

No. HTTPS and SSL/TLS validation are independent. Likewise, review domain ownership and registry records through the appropriate account and registration-data workflows. A branded certificate is useful presentation and platform verification evidence, not a substitute for those checks.

• Offer branded registration certificates through the WHMCS connector
• Use the live Domain Nexus OpenAPI contract for your integration
• Look up current domain registration data using RDAP
• Get started with the current Nabtech Domain Nexus v2 API