This API provides external access to the Micron21 Domain Panel application, giving admins, resellers, users, and the Micron21.com website API access to Domain Panels functionality to do things like verify domain availability, register new domains, query the registration status, transfer accounts and several other things.
\nThe Domain Panel host is https://domains.micron21.com/.
\nThe OTE host is internally addressable at https://client-area-staging.micron21.com/.
\nThere is a customer accessible OTE host at https://domains-ote1.micron21.com/. To get access to this, you will need a static IP address; please e-mail Joel McLean mailto:joel.mclean@micron21.com to be granted access.
\nThe API URL is be https://domains.micron21.com/api/v1/{call}/{parameter}/{argument}
\nSupported calls are:
\nGET
\nPOST
\nPUT/PATCH
\nDELETE
\nThis API documentation is version 1.0 as of 04/06/2021. Any issues or inconsistencies, please e-mail Joel McLean mailto:joel.mclean@micron21.com
\ncurl -X GET -H 'Accept: application/json' -H 'Authorization: Token token=\"dqzJsVcTkU4AxsbHJ9j8\", email=\"admin@example.com\"' \"https://client-area-staging.micron21.com/api/v1/customers/search?search_term=email&value=admin@example.com\"
Authentication is provided by an authentication token which is stored in the Domain Panel application and provided to users.
\nThere will be a specific authentication token for the Micron21 website.
\nThe format for authentication is in the header:'Authorization: Token token=\"dqzJsVcTkU4AxsbHJ9j8\", email=\"admin@example.com\"'
In POSTMAN this is achieved with variables (so you can set your own user + token when testing) and all Authorization is set to inherit from the parent API item.
\nFinally, the account needs to be explicitly enabled for API access; only an admin can enable a user for API access. The default setting is disabled for all users.
\nThe API Responses contain error messages that should generally be self-explaining. Some common errors that might not have a complete explanation are:
\n500 Internal Server Error - indicates bad request; something was malformed in such a way that the API wasn't able to respond with a coherent response. Check your inputs, target URL, authentication, and formatting.
\n401 Unauthorised (\"You are not permitted to perform that action\") - indicates that the endpoint is valid, and the authentication has been successful, but the thing you are trying to do is something you just are not allowed to do. This might be because you're trying to interact with a domain which belongs to a different user account.
\n401 Unauthorised (\"Unauthorized\") - indicates a problem with your username and authentication token. Check that you have these correct, contact support to have them reset and double check your account has API enabled.
\nError: read ECONNRESET - indicates that your API client was not able to connect to the remote server. For the OTE, this is likely because you are not accessing from an allowed IP address. For the production URL, it's possible you have a firewall rule in the way, or you have been blocked by our system for some ephemeral reason.
\nSpecial care needs to be taken when formatting specific fields in the request body:
\nMust be formatted YYYY-MM-DD with hyphens.
e.g. 1990-08-23
Contacts use a \"voice\" field which must be formatted either:
\nNNNNNNNNNN e.g. 0400123123 or;
+CC.A.PPPPPPPP e.g. +61.3.97517690
Must be two separate words. If a name would have multiple first names, they must be hyphenated.
e.g.
Steve Jobs for Steve Jobs
Mary-Anne Smith for Mary Anne Smith
Anything longer than one space is not supported.
\nWhere a country is required, it should be noted that ISO standard of 2 character country codes is required. \"Australia\" is not acceptable - AU in all capitals must be used.
Note: Search is an Admin Only function.
\nTo query a client account, we're searching by a token or a variable. All searches are case sensitive, (EXCEPT FOR EMAIL, as of patch 1.1411.1, email searches are case insensitive), and do not perform fuzzy matching - e.g. the user \"Joel McLean\" will only be found if the search term name and value Joel McLean exactly are used; case mismatch joel mclean or partial search Joel will match the result.
The returned data is a JSON Dataset of basically everything except the password, domains, and credit card for a given user.
\nThis is a GET request, so the params are parsed in the URL. Because of this, the BODY must be empty.
search_term params can be:
-> id ID is unique for users. This is only really useful to confirm an account exists, or for relational databases
-> email Email address is unique for users. This search term is case insensitive, forces uppercase to lower.
-> abn This not necessarily unique for users, if known. 11 digits only
-> acn This not necessarily unique for users, if known. 9 digits only.
-> name Names are not necessarily unique to one user
-> phone Phoneis not necessarily unique, but is consistently formatted
-> dob DOBs are not necessarily unique to one user
-> owns_domain Is meant to be an explicit match for a domain name. If you think in regex, think ^domain\\.au$ if your parameter was domain.au. This should only return a single result or no results.
-> by_domain allows you to search by partial match strings against the domain names, to return users who have domains that match the result. If you think in regex, think .\\\\\\*domain\\.au.\\\\\\*. This will generally return large arrays of users, and include the domain name that it matched against in the result.
Value is the string to search. name should match against a user's name, which can lookup the ID associated with it.
It is also technically possible to return multiple matches (i.e. mobile number) where a value is not unique. In these cases the JSON output will present the data in an array set.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Getting Customer Details is an Admin Only function.
\nOnce we know the ID of an account, we can return the contacts associated with that account.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Creating new customer accounts is an Admin Only function.
\nKeep in mind that data sets need to follow any valid formatting, which is covered in the introduction of this document.
\nOnce the API has received the request, it will verify if the customer is an existing customer or a new customer within the domain of the request. For example if it is a reseller it will check against the resellers client list for an existing client.
\nThe response will include the account customer ID which can be used to query the registration status.
\nAn error will be returned if the body data does not match the required data, or formats.
\nThe default client account will be created as a \"client\" access level, with no reseller parent.
\nValid client types are values are mapped as:{1 => \"Client\", 2 => \"Reseller\", 3 => \"Admin\", 4 => \"Hostbill\"}
when submitting client_type the value client, reseller, or admin should be used. hostbill is not yet supported.
Validation takes part in the client application, but if we expose this API to other applications we do want some error handling.
\nAPI Action will \"insert\" to \"users\" similar to the current \"create account\" function
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Updating Customer Details is an Admin Only function.
\nCustomer details can be updated, based on their customer ID which is unique to each customer.
\n\"name\" => optional\n\"email\" => optional\n\"password\" => optional\n\"address_1\" => optional\n\"address_2\" => optional\n\"address_3\" => optional\n\"suburb\" => optional\n\"postcode\" => optional\n\"state\" => optional\n\"country\" => optional //must be 2 Capital letters as per ISO standard\n\"mobile_number\" => optional\n\"company_name\" => optional\n\"company_number\" => optional //allows whitespace\n\"company_type\" => optional\n\"dob\" => optional\n\nNote: Creating Customer Contacts requires the API user to have privileges over the User ID
\nCreates a Contact to be used by domain registrations/updates
\nThere are two types of contact - Contact AU and Contact SRS. To save time we create both at once.
\nKeep in mind valid data types, which are covered at the start of this document.
\nOnce the API has received the request, it will create the contact object for the user specified, or if no user specified, then for the user who made the request. For example if it is a reseller it will check against the resellers client list for an existing client, if that client's user_id is specified.
\nThe response will include the contact ID which can be used to when registering a domain
\nAn error will be returned if the body data does not match the required data, or formats. Formatting details can be found under the heading \"Formatting\" at the start of this document
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Updating Customer Contacts requires the API user to have privileges over the User ID
\nUpdates a Contact to be used by domain registrations/updates. The body must include the ID of the contact to update.
\nThere are two types of contact - Contact AU and Contact SRS. To save time we update both at once.
\nPlease mind the data validation types, covered at the start of this document.
\nOnce the API has received the request, it will verify if the contact is an existing contact and within the user account of the request. For example if it is a reseller it will check against the resellers client list for an existing client, and that the contact belongs to it or it's child.
\nThere is a special case to note: if using this call to update a contact which is already assigned to a domain, the global contact will be updated, but the child-contact associated with the domain will not be updated. This means once the global contact is updated, any domain that you wish to push those changes to will need to be updated and have the contact reapplied using the \"Manage Domain\" call to reapply the contact.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Returning Customer Contacts requires the API user to have privileges over the User ID
\nReturns the details of a Contact to be used by domain registrations/updates. The URL must include the ID of the contact to return.
\nThere are two types of contact - Contact AU and Contact SRS. To save time we update both at once.
\nOnce the API has received the request, it will verify if the contact is an existing contact and within the user account of the request. For example if it is a reseller it will check against the resellers client list for an existing client, and that the contact belongs to it or it's child.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Deleting Customer Contacts requires the API user to have privileges over the User ID
\nReturns the details of a Contact to be used by domain registrations/updates. The URL must include the ID of the contact to return.
\nThere are two types of contact - Contact AU and Contact SRS. To save time we update both at once.
\nOnce the API has received the request, it will verify if the contact is an existing contact and within the user account of the request. For example if it is a reseller it will check against the resellers client list for an existing client, and that the contact belongs to it or it's child.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Checking Domains requires the API user to have privileges over the Domain, if it exists.
\nThis will check the domain, but also provide the price of the domain type.
\nThe full request string should look something like:
\nGET /api/v1/domain?domain_name=abc.com&user_id=123
The reseller can also use this to request verification of domain name availability to be registered.
\nThis call will need to work out whether a domain is fit for OpenSRS (TLDs) or Afilias (.au)
\nValid domain_name types are split out as:
ending in .au$ are checked against AU values
NOT ending in .au$ are checked against SRS values
This performs the multiple functions of:
\nDoes the domain exist?
\nIf it's \"au\" domain, is a single or launch domain? i.e. is a membership required?
\nIs the domain available for Registration?
\nIf information is available, what is the status of the domain?
\nWhat would be the price to register/renew the domain?
\nif the domain is controlled by micron21, and is not an AU domain, what is the expiry?
\nThere are approximately 323 different domain extensions for top level domains (TLDs). There are another set of 5 or so for .au extensions. Each may have a unique price.
\nFor the admin token this will provide the list price. If a user_id is provided, the price for that user (i.e. reseller custom pricing) will be provided.
For resellers this will provide their custom pricing. Prices are returned in cents.
\n{\n \"base_price\": \"1100\",\n \"reseller_price\": \"1430\" //only included if a user_id parameter is sent\n}\n\nNote: Checking Domains requires the API user to have privileges over the Domain, if it exists.
\nThis will check the domain, but also provide the price of the domain type.
\nThe full request string should look something like:
\nGET /api/v1/domain?domain_name=abc.com&user_id=123
The reseller can also use this to request verification of domain name availability to be registered.
\nThis call will need to work out whether a domain is fit for OpenSRS (TLDs) or Afilias (.au)
\nValid domain_name types are split out as:
ending in .au$ are checked against AU values
NOT ending in .au$ are checked against SRS values
This performs the multiple functions of:
\nDoes the domain exist?
\nIf it's \"au\" domain, is a single or launch domain? i.e. is a membership required?
\nIs the domain available for Registration?
\nIf information is available, what is the status of the domain?
\nWhat would be the price to register/renew the domain?
\nif the domain is controlled by micron21, and is not an AU domain, what is the expiry?
\nThere are approximately 323 different domain extensions for top level domains (TLDs). There are another set of 5 or so for .au extensions. Each may have a unique price.
\nFor the admin token this will provide the list price. If a user_id is provided, the price for that user (i.e. reseller custom pricing) will be provided.
For resellers this will provide their custom pricing. Prices are returned in cents.
\n{\n \"base_price\": \"1100\",\n \"reseller_price\": \"1430\" //only included if a user_id parameter is sent\n}\n\nNote: Registering Domains requires the API user to have privileges over the User ID, if specified.
\nRegister a new domain name.
\nThis can only happen on a pre-existing customer with a pre-existing contact.
\nA successful request will create an order; AU orders will require approval by an admin, where as SRS order should provision automatically should there be nothing wrong with the submitted data.
\nAn error will be returned if the body data does not match the required data, or formats.
\nlength_of_time_to_register defaults to 1 and must be set lower than the max_period for a given domain.
price is an optional field that will be ignored for all users except for admin access level users. If the price is specified the order will be raised with that price, instead of the reseller_price or base_price.
As a note, prepaid as a flag defaults to 1 if not present, and when set, changes the behaviour of the order. If a domain is registered with no prepaid flag set, or prepaid set to 1, then the order is generated but no charged are laid - this assumes payment has taken place in whatever system before this API call (i.e. hostbill, WHMCS, one page order form, etc). If we want Domain panel to attempt to charge the domain against the saved credit card (which the customer must have - otherwise it will fail) we can set \"prepaid\":\"0\" and that will change the order logic to charge the customer's credit card. Normal credit card handling applies.
Finally, for AU domains in the launch phase (March 2022 to September 2022) a Membership ID and Membership Auth codes can be provided with the regsitration request to register domains that require them. (A domain Check will confirm the requirements for an AU domain)
\nA full packet looks like:
\n{\n \"domain_name\": \"ote-md92161-single-00518.au\", \n \"contact_id\":1,\n \"user_id\": 1, \n \"auth_info\":\"asdASD123ASD!@#\",\n \"length_of_time_to_register\":\"2\",\n \"au_domain_contact\" : {\n \"eligibility_id_type\": \"ABN\",\n \"eligibility_id\": \"01234567890\",\n \"eligibility_name\": \"Business Name\",\n \"eligibility_type\": \"Charity\",\n \"registrant_id_type\": \"ABN\",\n \"registrant_name\": \"Other Business Name\",\n \"registrant_id\": \"01234567890\",\n \"policy_reason\": \"1\",\n \"registrant_agreement\": \"1\"\n },\n \"membership_details\":{\n \"membership_id\": \"m00000000300518\",\n \"membership_auth\": \"Au2uivPNsh0%xXlf\"\n }\n}'\n\nNote: Domain Details requires the API user to have privileges over the Domain
\nTo query a domain, we're searching by domain_name. For admin privileged users, this will return any domain, regardless of owner. For reseller or client privileged accounts, it will either return success with the domain if owned, or an unauthorised failure message if not owned or does not exist.
It should not be possible to return multiple matches in any set from a domain_name.
\nAs a note, up until recently, this return all domain information except for it's name servers and DS records.
\nName Server records should now display, and can be set using the Manage Domain PATCH API call.
\nDS records must use the dedicated \"sec_records\" API.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Refreshing Domains requires the API user to have privileges over the Domain
\nThis administrative function exists to tell a domain to re-sync from the registry.
\nThis should only be performed on domains that are active, as it can cause problems for domains pending_transfer or other transitive states. You can (and will) break your domains if you refresh them when they are in any state other than active.
\nAs a note, a successful refresh will return all domain information Domain Panel has after the refresh, except for it's name servers. These are presently not query-able using this API; however can be set using the Manage Domain PATCH API call.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Transferring Domains requires the API user to have privileges over the User ID, if specified.
\nThe domain transfer will require:
\nThe Domain Name (i.e. kanehooper.com.au). Domain type is gleaned from the extension (to AU or not to AU, that is the question.)
The Domain Password / Auth_info
\nTransfer contact details as per the register domain request.
\nAn optional User_id which admins use to nominate the account the domain will transfer into. Users/resellers making this call imply their own user id.
\nNote for a domain transfer to be successful the domain_locked status must be false.
\nThe request should execute a WHOIS beforehand to check the locked status and transferability of the domain to ensure a smooth transfer.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Renewing Domains requires the API user to have privileges over the User ID, if specified.
\nThe domain renew will require:
\nThe Domain Name (i.e. kanehooper.com.au)
The renewal period in years (1 to 5 for au, 1 to 10 for SRS)
\nmax_period comes into play here.Note for a domain renew to be successful the status must not be domain_renew_prohibited or any other status that prevents renewal.
Note: Managing Domains requires the API user to have privileges over the Domain
\nThis will allow resellers to manage particular attributes about domains that are managed by their organisation. Note that there is a special limitation when sending this patch command; when updating nameservers, all other parameters will be ignores, as the patch updates a separate part of the registry. This will hopefully be resolved in future updates, but for now, group the following 4 parameters together:
\nDomain-lock: Which prevents the registry from updating the domain in any way.
\nAuto-renew: Sets whether the renewal will be automatic or not.
\nDomain-password: This is used for transferring domain ownership.
\nDomain contacts
\nand only ever update these by themselves:
\nDomain Name Servers:
\nUpdate/remove
\nAdd
\nNote: Get Domain Registry information requires the API user to have privileges over the Domain
\nThis will allow admins to query the registrant information and attributes about domains to correct errors. Note that there is a special limitation when sending this patch command; only admins can use it.
\n\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Managing Domain Registry information requires the API user to have privileges over the Domain
\nThis will allow admins to manage the registrant information and attributes about domains to correct errors. Note that there is a special limitation when sending this patch command; only admins can use it.
\nThe full gamut of information should be supplied; for EPPConstants::ELIGIBILITY_TYPES and EPPConstants::REGISTRANT_ID_TYPES review the list below. Note that the registry does validation on the eligbility_id and registrant_id depending on what ID type is selected.
\nPolicy Reason is either 1 (Close and Substantial) or 2 (Exact Match or Abbreviation)
\n ELIGIBILITY_ID_TYPES = {\n 'ABN' => \"ABN\",\n 'ACN' => \"ACN\",\n 'ACT' => \"ACT State Identifier\",\n 'NSW' => \"NSW State Identifier\",\n 'NT' => \"NT State Identifier\",\n 'QLD' => \"QLD State Identifier\",\n 'SA' => \"SA State Identifier\",\n 'TAS' => \"TAS State Identifier\",\n 'VIC' => \"VIC State Identifier\",\n 'WA' => \"WA State Identifier\",\n 'TM' => \"Trademark Number\",\n 'ACECQA' => \"ACEQA\",\n 'ASL' => \"ASL\",\n 'CRICOS' => \"CRICOS\",\n 'RTO' => \"RTO\",\n 'TEQSA' => \"TEQSA\",\n 'OTHER' => \"Other\"\n }\n\n ELIGIBILITY_TYPES = [\n 'Body Serving Overseas Students',\n 'Charitable Trust',\n 'Charity',\n 'Child Care Centre',\n 'Citizen/Resident',\n 'Club',\n 'Commercial Statutory Body',\n 'Commonwealth entity',\n 'Company',\n 'Company Limited by Guarantee',\n 'Cooperative',\n 'Education and Care Services (Child Care)',\n 'Educational Institution',\n 'Government Body',\n 'Government School',\n 'Higher Education Institution',\n 'Incorporated Association',\n 'Indigenous Corporation',\n 'Industry Body',\n 'Industry Organisation',\n 'National Body',\n 'Non-Government School',\n 'Non-distributing Cooperative',\n 'Non-profit Organisation',\n 'Non-trading cooperative',\n 'Not-for-profit community group',\n 'Other',\n 'Parent and Professional Association/Organisation',\n 'Partnership',\n 'Peak State/Territory Body',\n 'Pending TM Owner',\n 'Political Party',\n 'Pre-school',\n 'Provider of Non-Accredited Training',\n 'Public/Private Ancillary Fund',\n 'Registered Business',\n 'Registered Organisation',\n 'Registrable Body',\n 'Religious/Church Group',\n 'Research Organisation',\n 'Sole Trader',\n 'Statutory Body',\n 'Trade Union',\n 'Trademark Owner',\n 'Trading Cooperative',\n 'Training Organisation',\n 'Trust',\n 'Unincorporated Association'\n ]\n\n REGISTRANT_ID_TYPES = {\n 'ABN' => \"ABN\",\n 'ACN' => \"ACN\",\n 'ACT' => \"ACT State Identifier\",\n 'NSW' => \"NSW State Identifier\",\n 'NT' => \"NT State Identifier\",\n 'QLD' => \"QLD State Identifier\",\n 'SA' => \"SA State Identifier\",\n 'TAS' => \"TAS State Identifier\",\n 'VIC' => \"VIC State Identifier\",\n 'WA' => \"WA State Identifier\",\n 'TM' => \"Trademark Number\",\n 'ACECQA' => \"ACEQA\",\n 'ASL' => \"ASL\",\n 'CRICOS' => \"CRICOS\",\n 'RTO' => \"RTO\",\n 'TEQSA' => \"TEQSA\",\n 'OTHER' => \"Other\"\n }\n\nNote: Checking Domain DNSSEC requires the API user to have privileges over the Domain.
\nOnly allowing the parameter: \"domain_name\" this should return the DS record information if there is any set, otherwise it will return a null set, or an error if the domain type is invalid or doesn't support DNSSEC.
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Manging Domain DNSSEC requires the API user to have privileges over the Domain.
\nA DNS server may sign a DNS zone with a key pair. If this is done properly, it should provide at least three pieces of information to support DNSSCE:
\nThe Hashing Algorithm
\nThe Digest Algorithm
\nThe Digest Hash
\nIt may optionally provide or suggest a key tag.
\nRead more about DNS SEC and how it is parsed by the registry here: DNSSEC via EPP: https://www.rfc-editor.org/rfc/rfc5910
\nRead more about the value types below:
\n| Key Tag | An integer value is used to identify the DNSSEC record. Value cannot be more than 65535. |
| Algorithm Type | The cryptographic algorithm that generates the signature. Allowed values are:
- 2 Diffie-Hellman
\n- 3 DSA/SHA-1
\n- 5 RSA/SHA-1
\n- 6 DSA-NSEC3/SHA1
\n- 7 RSASHA1-NSEC3/SHA1
\n- 8 RSA/SHA-256
\n- 10 RSA/SHA-512
\n- 13 ECDSA Curve P-256 with SHA-256
\n- 14 ECDSA Curve P-384 with SHA-384
\n- 253 Private [PRIVATEDNS]
\n- 254 Private [PRIVATEOID] |
| Digest Type | The algorithm type that constructs the digest. Allowed values are:
- 1 SHA-1
\n- 2 SHA-256
\n- 3 GOST
\n- 4 SHA-384 |
| Digest | The digest is an alpha-numeric string value. The length depends on the digest type used. Allowed values are:
SHA-1: 40 characters
\nSHA-256 and GOST: 64 characters
\nSHA-384: 96 characters |
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Must be true or false, can't be blank, but can be undeclared
\n","type":"text/plain"},"key":"push_to_registry","value":"false"}],"variable":[]}},"response":[{"id":"a16f431a-7a53-4b46-adc5-fc5bf3e5be2c","name":"Manage DNSSEC Record Success","originalRequest":{"method":"PUT","header":[],"body":{"mode":"raw","raw":"{\n \"sec\": {\n \"algorithm\": \"RSA/SHA1\", // Algorithm used for the DNS signing data\n \"digest_type\": \"SHA1\", // Digest type of the DNS Signing Data\n \"digest\": \"970744463fd89f65d5af9531103bf896c60a7134\", // A hash of the DS data. SHA1 must be 40chars, SHA2 64 chars, etc\n \"key_tag\": 46 // A unique key tag for the domain. Must be numeric between 1 to 65535\n }\n}\n","options":{"raw":{"language":"json"}}},"url":{"raw":"https://domains-ote1.micron21.com/api/v1/sec_records?domain_name=testdomainforpricefactor3.au&push_to_registry=true","host":["https://domains-ote1.micron21.com"],"path":["api","v1","sec_records"],"query":[{"key":"domain_name","value":"testdomainforpricefactor3.au"},{"key":"push_to_registry","value":"true","description":"Must be true or false, can't be blank, but can be undeclared"}]}},"status":"OK","code":200,"_postman_previewlanguage":"json","header":[{"key":"Server","value":"nginx"},{"key":"Date","value":"Fri, 01 Mar 2024 06:05:11 GMT"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Transfer-Encoding","value":"chunked"},{"key":"Connection","value":"keep-alive"},{"key":"Vary","value":"Accept-Encoding"},{"key":"X-Frame-Options","value":"SAMEORIGIN"},{"key":"X-XSS-Protection","value":"1; mode=block"},{"key":"X-XSS-Protection","value":"1; mode=block"},{"key":"X-XSS-Protection","value":"1; mode=block"},{"key":"X-Content-Type-Options","value":"nosniff"},{"key":"X-Content-Type-Options","value":"nosniff"},{"key":"X-Content-Type-Options","value":"nosniff"},{"key":"ETag","value":"W/\"d4326c1ae0f1e5c6fbc804643dd33c68\""},{"key":"Cache-Control","value":"max-age=0, private, must-revalidate"},{"key":"X-Request-Id","value":"a221a818-022e-44ce-8ccc-853f7f38cf3d"},{"key":"X-Runtime","value":"0.685642"},{"key":"Strict-Transport-Security","value":"max-age=31536000"},{"key":"Strict-Transport-Security","value":"max-age=31536000; includeSubdomains"},{"key":"Strict-Transport-Security","value":"max-age=0; includeSubdomains"},{"key":"Content-Encoding","value":"gzip"}],"cookie":[],"responseTime":null,"body":"{\n \"algorithm\": \"RSA/SHA1\",\n \"digest\": \"970744463fd89f65d5af9531103bf896c60a7134\",\n \"digest_type\": \"SHA1\",\n \"key_tag\": 46\n}"},{"id":"c6d6e63b-cb95-48cc-b942-53f884496302","name":"Failed - Manage DNSSEC Record Failure","originalRequest":{"method":"PUT","header":[],"body":{"mode":"raw","raw":"{\n \"sec\": {\n \"algorithm\": \"RSA/SHA1\", // Algorithm used for the DNS signing data\n \"digest_type\": \"SHA1\", // Digest type of the DNS Signing Data\n \"digest\": \"970744463fd89f65d5af9531103bf896c60a713\", // A hash of the DS data. SHA1 must be 40chars, SHA2 64 chars, etc\n \"key_tag\": 46 // A unique key tag for the domain. Must be numeric between 1 to 65535\n }\n}\n","options":{"raw":{"language":"json"}}},"url":{"raw":"https://domains-ote1.micron21.com/api/v1/sec_records?domain_name=testdomainforpricefactor3.au&push_to_registry=false","host":["https://domains-ote1.micron21.com"],"path":["api","v1","sec_records"],"query":[{"key":"domain_name","value":"testdomainforpricefactor3.au"},{"key":"push_to_registry","value":"false","description":"Must be true or false, can't be blank, but can be undeclared"}]}},"status":"Unprocessable Entity","code":422,"_postman_previewlanguage":"json","header":[{"key":"Server","value":"nginx"},{"key":"Date","value":"Fri, 01 Mar 2024 06:06:10 GMT"},{"key":"Content-Type","value":"application/json; charset=utf-8"},{"key":"Transfer-Encoding","value":"chunked"},{"key":"Connection","value":"keep-alive"},{"key":"X-Frame-Options","value":"SAMEORIGIN"},{"key":"X-XSS-Protection","value":"1; mode=block"},{"key":"X-Content-Type-Options","value":"nosniff"},{"key":"Cache-Control","value":"no-cache"},{"key":"X-Request-Id","value":"79be263e-a0cf-4265-8176-eafa62cf8c02"},{"key":"X-Runtime","value":"0.083173"},{"key":"Strict-Transport-Security","value":"max-age=31536000"}],"cookie":[],"responseTime":null,"body":"{\n \"digest\": [\n \"is the wrong length (should be 40 characters)\"\n ]\n}"}],"_postman_id":"466a9dd0-5de6-4450-b837-33f461b09c00"},{"name":"Update Credit Card","id":"1ede3652-3021-4ac4-8847-a7c68c15b4ea","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[{"key":"Content-Type","name":"Content-Type","type":"text","value":"application/json"}],"body":{"mode":"raw","raw":"{\n \"number\": \"4444333322221111\",\n \"month\": \"10\",\n \"year\": \"2025\",\n \"verification_value\": \"123\",\n \"first_name\": \"Test\",\n \"last_name\": \"Data\"\n}"},"url":"https://domains-ote1.micron21.com/api/v1/customers/1/credit_card","description":"Note: Updating a Credit Card requires the API user to have privileges over the User ID, if specified - otherwise, this acts on the user's own account.
\nCustomer payment information can be updated, based on their customer ID which is unique to each customer. This process should act identically to the /accounts page, where the option to \"save a new credit card\" simply updates the credit card on the account.
\nThe behaviour is that any \"new\" submission will overwrite the previous entry.
\nAs a note, in the staging OTE you can test with unencrypted credentials, but for production data, we will not accept unencrypted credit card information. This means that you must comply with eWay's asymmetric public key eCrypt process before submitting the data via the Domain Panel API. There are two ways to do this; by first making a call to eWay to encrypt the data, or using eWay's supplied eCrypt.js library to automatically encrypt data in a web-form on the client side.
\nFull reference:
\nhttps://eway.io/api-v3/#implementation
\nQuick reference:
\n1. Add the attribute data-eway-encrypt-key to the tag and set it’s value as the following Client Side Encryption Key.
<form action=\"#\" method=\"POST\" data-eway-encrypt-key=\"voSwxUH62ILxptCviYDqf6kqZXnhQ8XCtZYfdhosFqAbvM4swRkDYkk5cOlM1YiUcT/OSLtbBMd5WDloyu21yRMKslw8S/3V9CRa1gyMh7V/sTD7zvBscYj/BbCV6TB0NlRB7V7CuvLnqNJeECnx9KxjGgh7Qeuz2hSl1J7Z0TLAaYpddyqkZO8VXuxIAkhlLNMtfI4hI+I1JGZey84lhEVuuJP3eGewEgAvnnhvGMLfQ9TcGX5LsKIlmnvCkJgFe92jFDTVb84sTuhZzTCd4PQvYXtxz91+ek5774VV9nq34snsw5xxgN8yStbZ1yLve6TIQSP+zQb7Mi9KwZnaxw==\">\n\n2. Each form control to be encrypted must then have the attribute data-eway-encrypt-name and the control name you wish it to have.
<input type=\"text\" data-eway-encrypt-name=\"EWAY_CARDNUMBER\" />\n<input type=\"text\" data-eway-encrypt-name=\"EWAY_CARDCVN\" />\n\n3. After the form, include the eCrypt.js file:
\n</form> <script src=\"https://secure.ewaypayments.com/scripts/eCrypt.min.js\"></script>\n\nOnce you're sending encrypted data, production should work fine. Your form will need to use the post data with the name EWAY_CARDNUMBER and EWAY_CARDCVN.
\n4. Alternatives.
\nIt is possible to provide the encryption where a web form does not exist, for example, an app. eWay provide an SDK for IOS or android to encrypt data appropriately on the client.
\nFinally
\nTo delete the saved credit card, see the DELETE call Delete Credit Card below.
The information set is:
\n{\n \"number\" => required, //must be 16 digits with no spaces, i.e. 4444333322221111, and must be encrypted using eWay's encryption eCrypt\n \"month\" => required, //must be 2 digits, i.e. 09\n \"year\" => required, //must be 4 digits, i.e. 2024\n \"verification_value\" => required, //must be 3 digits, i.e. 123, and must be encrypted using eWay's encryption eCrypt\n \"first_name\" => required,\n \"last_name\" => required\n}\n\nValidation takes place in the API for CVV, number and the year and date formats. The year and month should be YYYY and MM respectively.
This data, in keeping with PCI, is not logged or stored - once submitted to the payment gateway, should not be retrievable.
\nThe response includes the token provided by the payment gateway (that is stored on the user's account)
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"Note: Deleting Credit Cards requires the API user to have privileges over the User ID, if specified, otherwise affects the user's own credit card.
\nThis API call deletes the saved credit card.
\nNo body information is required. Only the credit card of the authorised user can be deleted, or if the request comes from an admin account, any valid nominated customer account.
\nThe response includes the token provided by the payment gateway (that was stored on the users's account, before being deleted)
\n","auth":{"type":"apikey","apikey":{"basicConfig":[{"key":"key","value":"Authorization"},{"key":"value","value":"This will require further review from the technical team. There is presently no timeline for this to be implemented.
\nThere will need to be the ability to query existing host records as well as create new host records.
\nThe domain type needs to be known, just in case HOST IDs are not unique between domain platforms.
This might be more easily split into 4 calls:
Get Hosts
\nEdit Hosts
\nCreate Hosts
\nDelete Hosts
\nA host must always consist of either a hostname and an IPv4 address, or a hostname and an IPv6 address, or a hostname and both IPv4 and IPv6 addresses. The sponsored hostname must match the domain name.
\n{\n status: success,\n registry_id: \"M21-123234\" // or whatever the ID is in the registry; \n} \n\nid\nstate\ncreated_at\nupdated_at\nregistry_id\nhost_name\nip_v4_addresses\ndeleted_at\nip_v6_addresses\nuser_id // client_id\ndomain_id\n\n