> ## Documentation Index
> Fetch the complete documentation index at: https://developers.entri.com/llms.txt
> Use this file to discover all available pages before exploring further.
# DNS Provider Onboarding
> Register your DNS platform with the Entri Network so Entri can automatically configure DNS records on behalf of your users.
## Overview
Entri Network lets DNS providers (registrars, hosting companies, DNS platforms) register their APIs with Entri so that when a mutual user launches the Entri modal, Entri can configure DNS records automatically — no copy-paste required.
You configure your integration through the **Setup** wizard. It walks you through five steps:
1. **Provider profile** — how customers see you.
2. **Domain detection** — how Entri knows a domain is yours.
3. **Authentication** — how Entri logs into your API.
4. **DNS endpoints** — the routes Entri calls to read and write DNS records.
5. **Review & submit** — a final check before you go live.
You can move between steps freely. Each step is saved independently, and you must complete the required fields in a step before continuing. Once you're live, this same page becomes your editable settings.
This page documents every field in the wizard.
***
## Step 1 — Provider profile
> **Tell us who you are.** This is the brand customers see when they connect a domain to an app. It's also how Entri reaches you if something goes sideways.
### Brand
| Field | Required | Description |
| ----------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Provider name** | ✓ | The name shown to customers in the connect dialog (e.g. `DNSimple`, `Cloudflare`) |
| **Website** | — | Your company website URL |
| **Support email** | ✓ | Where customers reach you for connection help |
| **Logo** | — | Upload a square PNG or SVG, at least 64×64. Shown to users when they connect their domain via the Entri modal |
| **Brand color** | — | Used for buttons and highlights in the connect dialog. Click the swatch to open the color picker, or enter a hex value (e.g. `#006fee`) |
Your provider name may be pre-filled if Entri already has a record for your platform. You can edit it before saving.
### Manual fallback
Optional — a link to your own DNS instructions, in case Entri ever needs to send a customer to you to finish a connection.
| Field | Required | Description |
| --------------------------- | -------- | ---------------------------------------------------------------------- |
| **Manual instructions URL** | — | A link to your DNS help docs (e.g. `https://help.yourcompany.com/dns`) |
### Preview
Use **Preview in Entri** to see a snapshot of the provider card customers will see in the Entri picker.
***
## Step 2 — Domain detection
> **Help Entri recognize your customers' domains.** When someone enters their domain in Entri, we need to know it's managed by you. Pick one or both methods — Entri tries each in order.
### Nameserver match
If a domain's nameservers are yours, Entri knows it's on your service.
| Field | Required | Description |
| -------------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
| **Your nameservers** | ✓ | One nameserver hostname per line (e.g. `ns1.example.com`). Wildcards (e.g. `ns*.example.com`) are supported |
### DNS lookup (recommended)
Add a DNS record Entri can verify on every domain you manage. Useful if your nameservers vary.
| Field | Required | Description |
| ------------------- | -------- | ----------------------------------------------------------------------------- |
| **DNS Record Type** | ✓ | The record type Entri checks: `TXT` (recommended), `CNAME`, `A`, or `MX` |
| **Record host** | ✓ | The hostname Entri looks up (e.g. `_entri-verify`) |
| **Expected value** | ✓ | The value Entri expects to find at that host (e.g. `entri-verify=your-token`) |
DNS lookup is the most reliable method when your nameservers aren't fixed. Configure your platform to add the record above to every domain it manages.
***
## Step 3 — Authentication
> **Decide how Entri logs into your API.** You configure exactly **one** method per integration.
### Method
Choose one of the three authentication methods:
| Method | Description |
| ----------------------------- | ----------------------------------------------------------------------- |
| **OAuth 2.0** | Recommended. The customer signs in to your dashboard to authorize Entri |
| **Login (with optional MFA)** | The customer enters their username + password directly in Entri |
| **Basic Auth** | An API key sent as the `Authorization` header. Simplest for read-only |
### OAuth credentials
Shown when **OAuth 2.0** is selected. Find these in your OAuth app settings.
| Field | Required | Description |
| ---------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Client ID** | ✓ | The client ID for the Entri OAuth application registered in your system |
| **Client secret** | ✓ | The corresponding client secret — stored encrypted with AWS KMS |
| **Authorization URL** | ✓ | The OAuth authorization endpoint your users are redirected to |
| **Token URL** | ✓ | The token exchange endpoint |
| **Scopes** | — | Comma-separated OAuth scopes. Leave blank if your provider doesn't use scopes |
| **Entri redirect URI** | (read-only) | Entri's callback URI (e.g. `https://app.entri.com/auth/callback/`). Use **Copy** and add it to your OAuth app's allowed callback URLs |
With OAuth 2.0, Entri manages token injection automatically — you don't need to declare Authentication Parameters. Once the customer approves access, Entri sends the access token as `Authorization: Bearer ` on every subsequent API call.
### Authentication Parameters
Declare every value Entri injects into HTTP calls during authentication — the request field name, its location, and the static encrypted value Entri sends. Use **Add parameter** to open the drawer.
| Field | Required | Description |
| ---------------------- | -------- | ------------------------------------------------------------------------------------------------------------ |
| **Request Field Name** | ✓ | The header, query, body field name, or URL variable for path segments (e.g. `X-API-Key`) |
| **Location** | ✓ | Where the value is placed: `header`, `query`, `body`, or `url` |
| **Prefix** | — | A string prepended to the value before injection (e.g. `Bearer ` to produce `Authorization: Bearer `) |
| **Encrypted Value** | ✓ | The fixed value — the same for every user, stored encrypted at rest (e.g. `encrypted:kms:arn:aws:kms:...`) |
Authentication Parameters here carry **static** platform-level credentials (like an API key) that accompany every authentication call. OAuth 2.0 does not need them.
### Request signing
Shown for **Login** and **Basic Auth**. Optional — configure this if you need to verify that signed requests originated from the Entri platform. Entri signs the request body with its global RSA private key; you verify using Entri's public key.
| Field | Description |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Algorithm** | Signing algorithm — `SHA256withRSA` (read-only) |
| **Signature header** | HTTP header where Entri attaches the base64-encoded signature (e.g. `Sig`, `X-Entri-Signature`) |
| **Our public key ref (KMS ARN)** | KMS ARN Entri uses to export its public key (`kms:GetPublicKey`). Share the resulting key material with your platform so it can verify signatures |
Request signing is not applicable to OAuth 2.0.
***
## Step 4 — DNS endpoints
> **Wire up your DNS API.** Map each operation Entri needs to a route in your API. Complete every required row in the sidebar before you continue.
The sidebar lists the operations you must configure:
### List domains
`get_domains` — Returns all domains for the authenticated customer. Entri calls this to populate the domain picker.
The response should be a list of domains. Map your domain identifier and name fields to Entri's standard names in **Field mappings** if your API uses different names.
### Read DNS records
`get_records` — Returns all DNS records for one domain. Entri calls this to read the current record state before making changes.
Use `{variableName}` in the URL for the domain identifier returned by **List domains**. Map your record fields to Entri's standard names in **Field mappings** if needed.
### Record writes
Choose how your API creates and removes DNS records:
* **Separate** — configure **Add record** (`add_record`) and **Delete record** (`delete_record`) as individual endpoints.
* **Batch** — configure a single **Batch DNS records** (`batch_records`) endpoint that creates or updates multiple records in one call.
You only configure the rows for the shape you select.
### Update nameservers
`update_nameservers` — Replaces the nameservers for a domain. Entri calls this when delegating DNS management to your platform.
### Add WWW redirect
`add_www_redirect` — Creates a `www → root` redirect (or `root → www`). Used when a user points their domain to an application and needs web forwarding.
### Shared parameters
Values injected into **every** DNS endpoint call — sourced from the auth response or a static encrypted value. Use **Add parameter** to open the drawer.
| Field | Required | Description |
| ---------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Request Field Name** | ✓ | The header, query, body field name, or URL variable name for path segments |
| **Location** | ✓ | Where the value is placed: `header`, `query`, `body`, or `url` |
| **Prefix** | — | A string prepended to the value before injection |
| **Source** | ✓ | `auth` — extracted from the token/auth response via a JSON path. `static` — a fixed encrypted value, the same for every user |
| **JSON Path** | ✓ (if `source: auth`) | JSONPath to extract from the authentication response (e.g. `$.accessToken`) |
| **Static Value** | ✓ (if `source: static`) | The fixed value, stored encrypted — the same for every user |
***
## Endpoint configuration
Every DNS endpoint is described using the same set of fields.
### HTTP Request
| Field | Required | Description |
| --------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Method** | ✓ | HTTP method. Read endpoints (`get_domains`, `get_records`) are `GET`; write endpoints offer `POST`, `PUT`, `PATCH`, and (where valid) `DELETE` |
| **API URL** | ✓ | Full API URL. Use `{variableName}` for path variables — e.g. `https://api.yourcompany.com/v1/domains/{domainId}/records` |
| **Static Query Parameters** | — | Fixed query parameters appended to every request. Pagination parameters are managed automatically — don't add them here |
| **Request Headers** | — | Headers added to every call. `Authorization` is injected automatically from your auth parameters |
### Request Body
Shown for non-`GET` methods. JSON only.
Use `{{variableName}}` for template variables — values from the domain detection step or auth response are injected at call time. For example:
```json theme={null}
{ "name": "{{host}}", "type": "A" }
```
### Response Mapping
For **read** endpoints (`get_domains`, `get_records`), tell Entri how to read your API's response:
| Field | Required | Description |
| -------------- | -------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Data Path** | ✓ | JSONPath to the list/array in your response — e.g. `$.records`, `$.data.items`, or `$` if the response is the array itself |
| **Error Path** | ✓ | JSONPath to the error message in failed responses (e.g. `$.error.message`) |
For mutation endpoints (`add_record`, `delete_record`, `batch_records`, `update_nameservers`, `add_www_redirect`), only **Error Path** is shown.
### Field mappings
Map your API's field names to Entri's standard names. You only need entries for fields whose names **differ** from the standard — pick the Entri field from the dropdown for each of your fields.
Entri standard fields: `id`, `type`, `host`, `name`, `value`, `data`, `content`, `ttl`, `priority`, `srv.priority`, `srv.weight`, `srv.port`, `srv.target`, `mx.priority`, `mx.host`, `caa.flag`, `caa.tag`, `caa.value`.
Example — if your API returns `content` instead of `value`:
| Your field | Entri standard |
| ---------- | -------------- |
| `content` | `value` |
### Pagination
If `get_domains` or `get_records` returns paginated results, configure pagination so Entri fetches all pages automatically. Choose one of: `none`, `page_based`, `cursor_based`, or `offset_based`, then fill in the parameter names for that style.
Pagination parameters (page number, cursor, offset) are managed automatically by Entri. Do not add them as Static Query Parameters.
***
## Step 5 — Review & submit
> **Final check.** Take one more look. When you submit, Entri's team reviews your integration and flips you live in the network — usually within one business day.
The review screen summarizes everything you've configured, grouped into blocks:
* **Provider** — name, website, support email, logo, brand color.
* **Authentication** — method, OAuth credentials (if applicable), static auth parameters, and request-signing settings.
* **Domain detection** — the approach, your nameservers, and the DNS record check.
* **DNS endpoints** — the method and URL for each configured operation.
If any step is incomplete, the screen lists exactly what's left to finish before you can submit.
When everything is complete, choose **Submit for review**. After submission, the Entri team reviews and tests your configuration — you won't be able to make edits while it's in review. If your configuration passes, Entri publishes it into the Entri Connect modal and notifies you by email.
You cannot submit until every required field across all steps is complete.
***
## Submission checklist
Before submitting your integration, verify the following are configured:
* [ ] **Provider profile** — provider name and support email
* [ ] **Domain detection** — at least one method (nameserver match and/or DNS lookup)
* [ ] **Authentication** — one method (OAuth 2.0, Login, or Basic Auth) and its required fields
* [ ] **DNS endpoints**
* [ ] List domains (`get_domains`)
* [ ] Read DNS records (`get_records`)
* [ ] Record writes — either Add record + Delete record, or Batch DNS records
* [ ] Update nameservers
* [ ] Add WWW redirect