The API exposes the same operations the client area does, over HTTPS with JSON responses. Anything you can do to a domain in the browser, you can script. Get a key first Create an API key in the client area. Use a separate key per system so that revoking one does not break the others, and keep it on a server: a key in browser code or in a mobile bundle is a key you have published. Store it in an environment variable or a secrets manager, never in a repository. What you can do Domains: check availability, register, renew, and read status and expiry dates. DNS: read and set nameservers, and maintain DNS records. Privacy and contacts: set the privacy level and update the registrant, admin, tech and billing records. Orders and billing: read orders, invoices and payment status. Account: read the balance and basic account details. Design for failure before you need it Rate limits, network timeouts and upstream delays all happen. Retry idempotent reads freely. For anything that places an order, send a unique request reference and check it before writing again - otherwise a retried call can register the same domain twice. Log the reference, the domain and the response code for every call. When something is disputed later, those logs are the only proof that an action was taken. Trade-offs to think about Registration and renewal are real orders and cost real money: keep a balance or a working payment method, and test the flow on a small number of domains before pointing an automated system at a large batch. When something looks wrong Read the response body - it carries the reason, not just a status code. Then check the key is still active and the domain is in a state that allows the operation. If the answer is still unclear, open a ticket with the request reference and the time of the call.