Connect SDK

`entri.showEntri(config)`

This method launches the Entri modal window. config is an object — see Connect Configuration for the full list of properties and the showEntri() error reference.

`entri.checkDomain(domain, config)`

This asynchronous method checks the DNS configuration for a specified domain and returns details about the current DNS provider — including the registrar, supported DNS features, and, if NS records are passed, the authoritative DNS provider managing the zone file. Use it to determine whether Entri supports automatic setup for a domain. It accepts two arguments:

Argument	Type	Required?	Example
domain	string - a domain with no subdomain	Yes	example.com
config	Entri configuration object	Yes	See Connect Configuration
config.checkConflicts	Boolean	No	When checkConflicts is set to `true`, the system analyzes the DNS records provided in the dnsRecords array and determine whether any of them would require an override. The default value is `false`.

Important note: checkDomain function also requires you to provide the JWT authentication key within the configuration object. Refer to JWT authentication section for more information.

Sample usage:

const domainCheck = await entri.checkDomain("mydomain.com",
  {
    "applicationId": "myAppId",
    "token": "..."
    "dnsRecords": [
      {
        "host": "www",
        "ttl": 300,
        "type": "CNAME",
        "value": "cname.mydomain.com"
      },
      "checkConflicts": true, // Optional - Increases the response time
      //... etc
    ],
    //...other optional configuration keys
  }
)

HTTP endpoint

Premium tier and above.

You can also analyse the support for a domain with our http version of the checkDomain function.

POST https://api.goentri.com/checkdomain
Header "Authorization: [JWT authorization]"
Header "applicationId: [yourApplicationID]"

Request body

JSON

{
  "domain": "ifpiggiescouldfly.com",
  "dnsRecords": [
      {
        "host": "shop",
        "type": "CNAME",
        "value": "exampledestination.com",
        "ttl": "300"
      }
    ],
    "checkConflicts": true, // Optional - Increases the response time
    //... All the rest of the Entri Connect's configuration object
}

Sample Response

{
  "provider": "Cloudflare",
  "setupType": "Automatic",
  "NSSupport": {
    "root": true,
    "subdomains": true
  },
  "wwwRedirect": true,
  "cnameFlattening": true,
  "wildcardSupport": true,
  "subdomainCnameNsOverride": false,
  "spfOverrideSupport": false,
  "caaSupport": true,
  "supportsSocialLogin": "yes",
  "expired": false,
  "registered": true
}

For full detail, please refer to Response reference

Detecting Record Conflicts (`checkConflicts`)

When using the checkDomain function or endpoint, you can optionally enable DNS record conflict detection by adding the checkConflicts key to your configuration object.

checkConflicts: true // Optional — default is false

When enabled, Entri analyzes all DNS records passed in the dnsRecords array and compares them against the existing authoritative DNS configuration of the domain.
This helps you understand whether applying your desired configuration would require overwriting existing records.

How conflict detection works

If checkConflicts is set to true, Entri will:

Fetch the current DNS records for the relevant hostnames.
Compare them with the requested records.
Determine whether any requested record would overwrite existing DNS data.

A conflict is detected when:

A record with the same host and type already exists with a different value.
A CNAME conflicts with other record types on the same hostname.
Any record conflicts with an existing CNAME.
MX records differ from the existing set.
SPF TXT records would require merging or replacement.
An NS record subdelegates a hostname where other records are being added.

Response shape when `checkConflicts` is enabled

If enabled, the checkDomain response will include a new field:

"recordConflicts": null | [ ... ]

null → No conflicts detected
array → A list of detected conflicts, including details about the existing and requested records

Each conflict object follows this structure:

{
  "host": "www",
  "type": "CNAME",
  "value": "www.exampledomain.com",
  // "priority": "1" // Only for MX records
}

Example

{
  "provider": "Cloudflare",
  "setupType": "Automatic",
  "recordConflicts": [
    {
      "host": "www",
      "type": "CNAME",
      "value": "www.exampledomain.com",
    }, 
    {
      "host": "@",
      "type": "MX",
      "value": "mail.exampledomain.com",
      "priority": 1
    }, 
  ],
  "expired": false,
  "registered": true
}

Notes

Enabling checkConflicts increases response time because authoritative DNS lookups must be performed.
The data used for the analysis is gotten from the public domain DNS information.

If checkConflicts: true is provided without dnsRecords, the API will return an error.
This feature is designed to help partners determine whether prompting users about DNS overrides is necessary before running the automated setup.

Response reference

This section describes the response structure for the API endpoint or JavaScript function that checks the DNS provider information for a given domain. Depending on the DNS records passed as parameters, the response will include details about the domain’s registrar or the authoritative DNS provider currently managing the zone file.

Example 1: Standard DNS Records (No NS Records)

When the request contains DNS records that are not NS (Name Server) records, the response will include information about the current DNS provider, such as the provider name, setup type, and feature support details. Request:

{
  "applicationId": "myAppId", //Only JS function
  "token": "...", //Only JS function
  "domain": "entri.com",
  "dnsRecords": [
    {
      "host": "shop",
      "type": "CNAME",
      "value": "exampledestination.com",
      "ttl": "300"
    }
  ]
}

Response:

{
  "provider": "Cloudflare",
  "setupType": "Automatic",
  "NSSupport": {
    "root": true,
    "subdomains": true
  },
  "wwwRedirect": true,
  "cnameFlattening": true,
  "wildcardSupport": true,
  "subdomainCnameNsOverride": false,
  "spfOverrideSupport": false,
  "caaSupport": true,
  "supportsSocialLogin": "yes",
  "expired": false,
  "registered": true
}

In this case, the authoritativeDnsProvider field is not included because NS records were not part of the request.

Example 2: Request with NS Records

If NS records are provided in the request, the response will also include information about the authoritative DNS provider managing the zone file. Request:

{
  "applicationId": "myAppId", //Only JS function
  "token": "...", //Only JS function
  "domain": "entri.com",
  "dnsRecords": [
    {
      "host": "@",
      "type": "NS",
      "value": "ns1.exampledestination.com",
      "ttl": "300"
    }
  ]
}

Response:

{
  "provider": "Cloudflare",
  "setupType": "Automatic",
  "NSSupport": {
    "root": true,
    "subdomains": true
  },
  "wwwRedirect": true,
  "cnameFlattening": true,
  "wildcardSupport": true,
  "subdomainCnameNsOverride": false,
  "spfOverrideSupport": false,
  "caaSupport": true,
  "supportsSocialLogin": "yes",
  "authoritativeDnsProvider": {
    "provider": "Cloudflare",
    "setupType": "Automatic",
    "wwwRedirect": true,
    "cnameFlattening": true,
    "wildcardSupport": true,
    "subdomainCnameNsOverride": false,
    "spfOverrideSupport": false,
    "caaSupport": true,
    "supportsSocialLogin": "yes"
  },
  "expired": false,
  "registered": true
}

In this case, the authoritativeDnsProvider object is included because NS records were passed, providing details about the provider managing the zone file.

Response Parameters

provider: The current DNS provider for the domain, either based on common DNS records or NS records if provided.
setupType: Indicates whether automatic setup is supported for the DNS provider. If not, a manual setup flow will be presented.
NSSupport: Object that specifies whether the provider supports nameserver configurations at the root or subdomain levels:
- root: true if root-level nameserver configuration is supported.
- subdomains: true if subdomain-level nameserver configuration is supported.
wwwRedirect: Indicates whether the provider supports automatic root domain-to-www redirects.
cnameFlattening: Specifies whether the provider supports CNAME flattening (resolving CNAMEs at the root level).
wildcardSupport: Indicates if wildcard DNS entries (e.g., *.domain.com) are supported by the provider.
subdomainCnameNsOverride: If true, the provider will automatically remove a CNAME record when a subdomain nameserver with the same name is added.
spfOverrideSupport: Determines how Entri handles SPF record updates. true if Entri can completely replace the existing SPF record with a new value. false if Entri can only append new values to the existing record or create a new one if no SPF record is present.
caaSupport: Determines wether the provider supports CAA records or not.
supportsSocialLogin: Specifies whether Entri supports social network logins for the provider. "yes" if Entri supports social login for this provider. "no" if Entri does not support social login for this provider. "n/a" if the provider does not support social login, so this setting does not apply.
expired: Boolean value indicating if the domain’s current DNS setup has expired.
registered: Boolean value indicating whether the domain is registered.
authoritativeDnsProvider (only included when NS records are provided in the request):
- All the same fields as the above, but apply only to the authoritativeDnsProvider

This response format helps users understand the current DNS configuration and determine whether the provider supports certain advanced features like wildcard records, CNAME flattening, and subdomain overrides.

`entri.checkRecords(domain, config)`

This asynchronous method checks whether the DNS records you wish to configure are already present and correctly resolving on a given domain. Use it to determine whether an automated flow is still needed, or to build your own status UI on top of Entri.

Argument	Type	Required?	Example
domain	string	Yes	`example.com`
config	Entri configuration object	Yes	See Connect Configuration

The configuration object must include applicationId, token, and the dnsRecords array to be verified.

Sample usage:

const result = await entri.checkRecords("mydomain.com", {
  applicationId: "myAppId",
  token: "...",
  dnsRecords: [
    { host: "www", ttl: 300, type: "CNAME", value: "cname.mydomain.com" }
  ]
});

The response reports, per record, whether it is already propagated or still missing.

`entri.close()`

This method will force closing the modal and also trigger the onEntriClose() event with the last step details. Please refer to the onEntriClose for more information.

`entri.load()`

This method on the NPM package loads the EntriJS script so it’s ready for use when called.

`entri.loadSharedFlow(url)`

This method launches the Entri Connect modal using a shared‑link configuration. entri.loadSharedFlow(url) accepts a single parameter:

Argument	Type	Required?	Description
`url`	string	Yes	A sharing‑link URL that contains a previously saved Entri configuration.

How it works

The function receives a sharing‑link URL.
Entri fetches the configuration stored within that sharing link.
Once retrieved, Entri automatically initializes the flow and opens the Entri Connect modal.
The experience is identical to calling entri.showEntri(config) with the same configuration object.

Example usage

entri.loadSharedFlow("https://example.com/shared/abc123");

Notes

The shared‑link must contain a valid configuration generated by Entri’s sharing‑link feature.
Any callbacks such as onEntriClose or onSuccess will behave the same as when using entri.showEntri().
Errors related to invalid or expired shared links will surface in the console with the corresponding error code.

Get Started

Entri Activate

Entri Connect

Entri Sell

Entri Power

Entri Secure

Entri Monitor

Entri Network

Entri MCP

DNS Concepts

Reference

Legal & Security

`entri.showEntri(config)`

`entri.checkDomain(domain, config)`

Sample usage:

HTTP endpoint

Request body

Sample Response

Detecting Record Conflicts (`checkConflicts`)

How conflict detection works

Response shape when `checkConflicts` is enabled

Example

Notes

Response reference

Example 1: Standard DNS Records (No NS Records)

Example 2: Request with NS Records

Response Parameters

`entri.checkRecords(domain, config)`

Sample usage:

`entri.close()`

`entri.load()`

`entri.loadSharedFlow(url)`

How it works

Example usage

Notes

​entri.showEntri(config)

​entri.checkDomain(domain, config)

​Sample usage:

​HTTP endpoint

​Request body

​Sample Response

​Detecting Record Conflicts (checkConflicts)

​How conflict detection works

​Response shape when checkConflicts is enabled

​Example

​Notes

​Response reference

​Example 1: Standard DNS Records (No NS Records)

​Example 2: Request with NS Records

​Response Parameters

​entri.checkRecords(domain, config)

​Sample usage:

​entri.close()

​entri.load()

​entri.loadSharedFlow(url)

​How it works

​Example usage

​Notes

`entri.showEntri(config)`

`entri.checkDomain(domain, config)`

Sample usage:

HTTP endpoint

Request body

Sample Response

Detecting Record Conflicts (`checkConflicts`)

How conflict detection works

Response shape when `checkConflicts` is enabled

Example

Notes

Response reference

Example 1: Standard DNS Records (No NS Records)

Example 2: Request with NS Records

Response Parameters

`entri.checkRecords(domain, config)`

Sample usage:

`entri.close()`

`entri.load()`

`entri.loadSharedFlow(url)`

How it works

Example usage

Notes