Netim Registrar — setup and reference

Module and release scope

This guide covers Netim Registrar 1.0.0, Extension API 1, from the reviewed product source. Its declared core range is 1.3.6–1.3.99. Use the matching released core and signed provider package; a version label alone does not install the required contracts. Source availability does not mean the module is bundled in every currently downloadable product, installed on your server, enabled or certified for your merchant/server account. Nothing in this guide enables a provider or changes your existing connections.

Open System → Domain registrars (newer source may group these as Payments, Domain services or Hosting services). Install the reviewed signed package through Modules & addons or the integration workspace's Install tab, enable the module separately, add an account/connection, save its own credentials, run its stated Test and explicitly enable the connection. Saving or retesting disables the connection until you enable it again. Start with the provider's test environment where supported; otherwise use an isolated account or server.

Exact connection fields

These are the fields declared by this module. Secret values are entered privately and encrypted by the application. Defaults are configuration hints, not approved live merchant settings. Internal fields are populated by the module and are not operator-editable.

Key / label	Type	Required	Default / guidance
reseller_id — Reseller account ID	text	Yes	Use the account-specific value described below.
api_password — API / DAS password	secret	Yes	Use the account-specific value described below.
allow_writes — Allow domain purchases and changes	boolean	No	Default: false
allow_automated_renewals — Allow paid-invoice automated renewals	boolean	No	Default: false

The Netim package uses the operational REST 1.0 interface. Netim's published 3.0 guide identifies that version as unreleased, so this adapter does not assume those future request shapes. Installation leaves the module disabled and creates no reseller connection or domain.

Configure

1. Open your Netim reseller account's API – DAS – OTE settings. Obtain the reseller account ID and API/DAS password, and request API authorization if it is not already active. The normal account login password is not the API password.
2. Create a Netim registrar connection and enter those encrypted credentials. The production origin is fixed to https://rest.netim.com/1.0/.
3. Run Test. It opens an authenticated session using POST /session/ and validates the returned access token; it changes no domain or contact. Other requests use the returned bearer token. A failed credential test will show safe provider and HTTP diagnostics.
4. Enable the connection and map supported TLDs. Enable purchases only after checking your reseller balance, registry rules and contact eligibility. Paid-invoice automated renewal is separately disabled by default.

Netim documents its OT&E REST endpoint with HTTP. This package deliberately has no HTTP test environment option and will not send reseller passwords over that endpoint. Use provider-approved HTTPS testing or a staging/funded account with purchases disabled until you deliberately enable them. No Netim webhook is required by this adapter.

Operations

Operation	REST 1.0 endpoint
Availability	GET /domain/{domain}/check/
Registration	POST /domain/{domain}/
Incoming transfer	POST /domain/{domain}/transfer/
Renewal	PATCH /domain/{domain}/renew/
Account domain readback	GET /domain/{domain}/info/
Nameserver change	PUT /domain/{domain}/dns/
Registrar lock change	PATCH /domain/{domain}/preference/ with registrar_lock
Transfer code	Authenticated domain authID field

The module creates a registrant contact with isOwner=1 and a separate administrative contact with isOwner=0 using the owning customer's billing contact. It never assigns the reseller's business details as customer ownership. Technical and billing roles share that customer's administrative handle. Optional input.idOwner and input.idAdmin let an administrator reuse existing contact handles, but they are authenticated and compared against the intended customer before any domain purchase. Optional input.contact_additional passes registry-specific additional contact values; local registry eligibility must still be reviewed.

A domain creation may create contact records before the billable domain submission. A contact-stage failure is reported as no domain purchase submitted, so operators can distinguish those partial prerequisites from an uncertain billable purchase. Registrations support explicit 1–10 year terms and 2–5 nameservers; incoming transfers accept the provider's single transfer term and require the transfer authorization code. Premium, launch, trustee, restore and trade flows require manual handling.

After registration the module requests auto_renew=0. If that preference cannot be confirmed, the registration remains pending for review. Existing provider preferences are not changed by synchronization or a renewal.

Completion and diagnostics

An operation's Done or Pending status is not treated as proof that the customer's domain is active. Fresh account-owned readback must match the domain, active/delegated state, real expiry, nameservers and the complete registrant contact fetched through its owner handle. A renewal additionally needs the complete requested extension beyond the pre-submission expiry. Pending registry operations remain pending, and incoming transfers remain asynchronous. A timeout after submission is never automatically retried.

All requests verify TLS, prohibit redirects and retries, set connection/total timeouts and enforce a 2 MB uncompressed response limit. Diagnostics redact credentials, generated authentication headers and customer data. Transfer codes are excluded from routine synchronization.

Provider documentation

• Operational REST 1.0 guide and credentials
• REST 1.0 domain operations
• Contact creation
• Domain and operation state definitions