Activation & Licensing

Natsura contacts api.keygen.sh over HTTPS to validate your key. If that request fails for any reason, no internet, DNS, firewall, antivirus, proxy or VPN, the check fails and your trees go empty.

Check it from a terminal. On Windows, open Command Prompt (Windows key, type cmd):

nslookup api.keygen.sh
curl.exe -I https://api.keygen.sh/

In PowerShell, curl is an alias for a different command, so type curl.exe with the extension to get the real one.

Read the pair together, because the combination is what identifies the cause:

Check it from inside Houdini. This is the test that decides it, because it uses the exact interpreter and network settings Natsura uses. Open Windows, Python Shell and paste:

import socket, os, requests
print(socket.gethostbyname("api.keygen.sh"))
print({k: v for k, v in os.environ.items() if "proxy" in k.lower()})
print(requests.get("https://api.keygen.sh", timeout=10).status_code)

An address and a status code, any number, means the path Natsura uses is healthy. socket.gaierror means the name cannot be resolved. SSLError means HTTPS is being intercepted. A printed proxy variable means Houdini routes through a proxy, and that proxy has to allow api.keygen.sh. It is normal for Command Prompt to succeed while this fails.

On macOS, use dscacheutil -q host -a name api.keygen.sh and scutil --dns | head -40. Look for resolvers you did not set, check /etc/hosts and /etc/resolver/, and look under System Settings, General, VPN & Device Management for a profile installed by a VPN, a security product or an employer. Clear the cache with sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder.

On Linux, use getent hosts api.keygen.sh, resolvectl status and dig @1.1.1.1 api.keygen.sh. getent uses the same path Python does, so it is the one that matters. If dig succeeds and getent fails, the problem is in nsswitch.conf or systemd-resolved rather than at the DNS server.

Behind a corporate proxy, add this to your houdini.env, which lives in your Houdini user folder and is named for your Houdini version, not for the Natsura package folder:

HTTPS_PROXY = http://your-proxy-host:port

Restart Houdini afterwards, because houdini.env is only read at startup.

A temporary way to keep working. This is a stopgap, not a fix, and it will eventually break without warning when our licence host changes addresses. Open Notepad as administrator, open C:\Windows\System32\drivers\etc\hosts, and add:

3.33.148.61 api.keygen.sh

Save, then confirm with curl.exe -I https://api.keygen.sh/. Delete that line once name resolution works on its own, or you will be relying on an address that may stop being ours.

Confirming it is fixed. You do not need to restart Houdini. Recook any Natsura node and the check runs again. The last line of license_validation.jsonl should read "result": 1, "result_name": "PASSED". If this machine had never activated before, that cook is its first activation and it uses one of your machine slots.

If nslookup returns addresses but curl says Could not resolve host, the address is fine and your router is fine. The name resolution stack on your machine is refusing the lookup. nslookup asks the DNS server directly and bypasses that stack, which is why it succeeds.

This is the case that takes longest to solve, because the usual suspects are often innocent. Changing network, disabling antivirus and disconnecting a VPN frequently change nothing. The cause is usually a piece of software that installed itself into the resolver and keeps working whether or not its application is running. Work the stages in order rather than guessing.

Run these in PowerShell. Some need an administrator window: right-click the Start button and choose Terminal (Admin).

Stage 1, how wide is the failure?

curl.exe -I https://example.com
curl.exe -I https://api.github.com
curl.exe -I https://keygen.sh
curl.exe -I https://api.keygen.sh/
ping api.keygen.sh
Resolve-DnsName api.keygen.sh

Also open https://api.keygen.sh in your browser. A short page of error text counts as success, it means the address resolved.

Stage 2, inspect the configuration. Each of these is normally empty or absent. Anything populated is a lead.

Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize
Get-DnsClientNrptPolicy
Get-DnsClientDohServerAddress
Get-DnsClientGlobalSetting
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-Service Dnscache
Select-String keygen C:\Windows\System32\drivers\etc\hosts
(Get-Item C:\Windows\System32\drivers\etc\hosts).Length

A DNS server of 127.0.0.1, or any other address on your own machine, means a program here is acting as your DNS server, and that program is almost certainly the cause. Anything returned by Get-DnsClientNrptPolicy is a name resolution rule, usually left by a VPN or management tool, and it applies even when the VPN is disconnected or uninstalled. If encrypted DNS is configured and that server is unreachable, resolution fails while nslookup still works: turn it off to test under Settings, Network & Internet, your connection, DNS server assignment, Edit, and turn it back on if that was not the cause. In Get-DnsClientGlobalSetting, a SuffixSearchList can mean the system is looking up api.keygen.sh.<suffix> and failing while nslookup asks for the name exactly as typed. Dnscache must be Running. A default hosts file is under 1,000 bytes; one that is tens of thousands, from an ad blocking list, can interfere in ways that are hard to see.

Two commands that pin down where the failure happens:

Resolve-DnsName api.keygen.sh -Server 1.1.1.1
Resolve-DnsName api.keygen.sh -NoHostsFile

If the first works and a plain Resolve-DnsName does not, your upstream DNS is fine and the problem is local. If the second works and a plain one does not, your hosts file is involved.

Stage 3, find the software.

Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, OwningProcess
netsh winsock show catalog | Select-String "Description"
Get-Service | Where-Object Status -eq Running |
  Select-Object Name, DisplayName | Sort-Object DisplayName

The first shows any program listening for DNS on this machine. The second lists software hooked into Windows networking, where on a clean install every entry is from Microsoft. Anything that is not is a lead. Categories worth scanning the service list for: network filters and privacy firewalls, system wide ad blockers and DNS filtering clients, parental control and web protection suites (the web protection component is a separate service from the antivirus you may have already disabled), VPN clients including ones that route only DNS, and leftovers from software you have already removed.

Stage 4, repairs. Least invasive first, retrying curl.exe -I https://api.keygen.sh/ after each:

ipconfig /flushdns
Restart-Service Dnscache
Get-DnsClientNrptRule | Remove-DnsClientNrptRule

If none of that helps, reset the networking stack. This removes third party entries that survive uninstalling the software that created them, and it is the step that most often fixes a resolver nothing else explains. It needs an administrator window and a restart, and it resets other network customisations, so if this machine uses a fixed IP address, write the settings down first.

netsh winsock reset
netsh int ip reset

Stage 5, change your DNS servers. Worth doing either way, because it removes a variable: Settings, Network & Internet, your connection, Hardware properties, DNS server assignment, Edit, Manual, IPv4 on, then 1.1.1.1 and 8.8.8.8. Then ipconfig /flushdns. Both providers support encrypted DNS, so you can leave that on.

If none of it works, send us the output of stages 1 and 2. That is a complete picture of the resolver and it tells us in one read what your machine is doing.

Natsura looks in two places, in order: the path recorded in shared_prefs.json under license.file_path, if it is an absolute path, and then the default location.

Windows   %APPDATA%\natsura\license.lic
macOS     ~/Library/Application Support/natsura/license.lic
Linux     ~/.config/natsura/license.lic

Confirm the file exists at one of those, that it contains your key and nothing else, and that it has not been quarantined by security software. If you moved your Natsura install, the recorded path can still point at the old location.

Natsura ships a separate download per tier, and the tier is checked against Houdini's own licence category when a tree cooks. Read the last line of the validation log: tier is what you installed and houdini is what Houdini reports. They have to be compatible, so an Indie Natsura build on Commercial Houdini, or a Studio build on Indie Houdini, will not validate.

The fix is to install the correct download for your Houdini licence. Follow Upgrading: delete the old package folder first, then unzip the correct one. Do not unzip one tier on top of another. See Commercial Use for how the two licences relate.

Each Natsura licence activates on up to two machines. This happens more often than the machine count suggests, because a machine is identified by its hardware, and significant hardware or operating system changes can make the same computer look like a new one.

Email support@natsura.com from the email address on your account and tell us which machine to release. We can reset it. Do not include your licence key.

The server answered and refused the key: an expired subscription, or a licence that has been revoked or suspended. Check the subscription on your account, and if it looks current, email us from your account address with the log line. Do not send the key itself.

Apprentice builds confirm the current date using an internet time service rather than the licence server. FAILED_DATE_FETCH means that did not come back.

Two causes. Your system clock may be wrong: turn on automatic time synchronisation, confirm the time zone, and retry. Or your network blocks time synchronisation, which some firewalls do while allowing ordinary web traffic. Trying a different network confirms it quickly, and your IT team can allow it if you are on a managed machine.

Because this uses a different service from everything else on this page, it can fail on a machine where every other check here passes.

Natsura can log everything it does apart from the licence check: Settings, Diagnostics, Verbose logging, or set NATSURA_LOG_VERBOSE = 1 in your houdini.env if you cannot reach the settings. That output goes to the session log:

Windows   %APPDATA%
atsura\logs
atsura-YYYY-MM-DD-HHMMSS.log

houdini.env is a plain text file in your Houdini user folder, named for your Houdini version, not for the Natsura package folder. It is only read at startup, so restart Houdini after editing it.

The licence check does not appear in that log. It records to license_validation.jsonl instead, which is what the top of this page describes. If we need more detail than those lines carry, we will send you instructions when you get in touch.

Rather than gathering files by hand, run this in Houdini's Windows, Python Shell. It prints a complete picture of your activation state and tests the connection, and it does not print your licence key.

import os, sys, socket, platform, json
from pathlib import Path
import requests, hou

base = (Path(os.environ["APPDATA"]) if sys.platform == "win32"
        else Path.home() / "Library/Application Support" if sys.platform == "darwin"
        else Path.home() / ".config")
data = base / "natsura"

print("Houdini       ", hou.applicationVersionString(), "|", hou.licenseCategory().name())
print("Platform      ", platform.platform())
print("Natsura data  ", data, "| exists:", data.exists())
print("$NATSURA      ", hou.expandString("$NATSURA"))

for name in ("license.lic", "license.json", "shared_prefs.json"):
    print(f"  {name:<22}", "present" if (data / name).exists() else "MISSING")

log = data / "license_validation.jsonl"
if log.exists():
    print("Last validations:")
    for line in log.read_text().strip().splitlines()[-5:]:
        print("  ", line)
else:
    print("No validation log: the licence check has never run on this machine.")

try:
    print("DNS           ", socket.gethostbyname("api.keygen.sh"))
except OSError as exc:
    print("DNS            FAILED:", exc)

try:
    print("HTTPS         ", requests.get("https://api.keygen.sh", timeout=10).status_code)
except requests.RequestException as exc:
    print("HTTPS          FAILED:", type(exc).__name__, exc)

The output contains no licence key and no secrets. It does contain your computer's user name, because that appears in the file paths, so send it to support directly rather than posting it in a public forum.

All in your Natsura user data folder, %APPDATA%\natsura\ on Windows:

If license.json has never appeared, no check has ever succeeded on this machine, which points at the network rather than at the key.