This document explains in detail the semantics of the function calls you can make using the Registry Compliance API service. This service is limited to access by approved senders and E-mail Service Providers (ESPs) who have (1) completed the information required by the governments to access their compliance programs, (2) been approved by these governments for access, and (3) agreed to the required license terms.

In this document, you will learn:

• How the Registry Compliance API syntax works and how operations are performed.
• How to format and upload lists to be scrubbed.
• How to limit your scrubbing process to particular jurisdictions or laws.
• How to interpret the results you receive back from the Registry Compliance systems.
• What error codes you may encounter mean and how to resolve them.

This document is subject to change. The latest version of this document is always maintained at:

https://www.registrycompliance.com/api_spec.html

We have built prototypes of applications to interact with the Registry Compliance system. To see these prototypes, please visit:

https://www.registrycompliance.com/samples/

If you have comments, find errors, or have questions, please contact apisupport@registrycompliance.com.

Interaction with the Registry Compliance system is accomplished with POST requests through the secure HTTP protocol (HTTPS). This protocol was chosen for its simplicity, network administrators' familiarity with it, its ability to pass through many corporate firewalls without requiring their modification, the protocol's extensive documentation, and the wide availability of access tools written in many languages.

Some links concerning establishing and performing POST requests over secure HTTP sessions are provided below:

• Perl (LWP)
• Java (HttpsURLConnection
• PHP (fsockopen)
• Python (urllib)
• Windows (WinInet | HttpWebRequest Class)

There are some general issues that you should keep in mind when designing an application for interacting with this API. You may want to refer to this checklist as you are constructing the application. Neglecting to follow these general guidelines is the usual source of difficulty for application designers.

• All requests should be established via a secure SSL connection through the HTTPS protocol.
• All operation requests are initiated via a POST request from the client to the Registry Compliance system.
• Files must be transferred in binary format. Compression is not necessary and will not reduce the size of the files since the hashed data approximates randomness.
• Binary files should be setup byte-wise with the high-nibble first.
• You may include a maximum of 2.5 million entries per file, or approximately 40 megabytes. You may, however, attach up to 50 files to a single task and scrub them all at the same time for a maximum of 125 million entries checked per scrub task.
• Unless otherwise specified, entries should be converted to lowercase and all spaces should be removed before being hashed. Non-numeric characters should be removed from phone numbers.
• Unlike entry hashes which are in binary format, all file checksums are MD5 hashes in HEX format.
• Because they may include restricted characters, whenever salts are exchanged, they are passed URL-encoded. They should always be URL-decoded before they are used.
• The order in which you pass the POST parameters does not matter.
• The precise order of the fields in the XML responses, as described in the examples in this document, may change and should not be relied upon.
• All fees are rounded to the nearest whole penny. 1/10th - 4/10ths of a cent are rounded down (i.e., $108.004 → $108.00). 5/10ths - 9/10ths are rounded up (i.e., $108.005 → $108.01).
• For added security, your access to the API is restricted to the set of IPs you listed when you created your account. You may change these IPs if your setup changes.

The Registry Compliance system was designed to maintain the privacy and security of the lists that are uploaded for scrubbing. At no time do the e-mail addresses or other contact points being scrubbed leave the sender's client machine. Instead, only hashes of the e-mail addresses or other contact points are transmitted. To ensure this level of security, a sender's list must be hashed and formatted before being uploaded to the Registry Compliance system.

Entries on a sender's list should be hashed using MD5 hashing. MD5 was chosen for its speed and wide availability across multiple programming languages (see RFC 1321).

Binary and HEX MD5 is supported natively or in widely available libraries across most modern languages. References to some of these libraries are listed below:

• Perl (Digest::MD5
• Python (md5)
• PHP (MD5 Manual)
• C++ (Crypto++)
• .NET (MD5CryptoServiceProvider Class)

Before hashing, each entry must be combined with the entry's type and the current salt provided by the Registry Compliance system. An entry's type is pre-pended to the beginning entry; salts are appended to the end of each entry. The MD5 function should generally be formed as follows:

• MD5([type][entry][salt])

Types are represented by a three-character, upper-case code. Currently, the system supports all of the following types:

• EML - E-Mail Addresses
• DMN - Domains (associated with e-mail addresses)
• FAX - Fax Numbers
• SMS - Mobile Device Numbers/ SMS
• TWT - Twitter Handles
• IGR - Instagram Handles
• SNP - Snapchat Handles
• YTB - YouTube Handles
• TOK - TicToc Handles
• TCH - Twitch Handles
• DCR - Discord Handles

Please ensure that type codes are always rendered in uppercase when constructing your MD5 hashing function. The actual entry, on the other hand, should be reduced to lower case before hashing. In other words:

• JOHN.DOE@EXAMPLE.COM → john.doe@example.com
• John.Doe@Example.com → john.doe@example.com
• JoHn.DoE@eXaMpLe.CoM → john.doe@example.com

Do not remove valid characters from e-mail addresses.

For types FAX and SMS, any non-numeric characters (including spaces) should be stripped before hashing. Area codes must be included in phone numbers. Any leading "1" should be stripped from the number. A 10-digit number is expected. For example:

• (517) 555-1212 → 5175551212
• 517-555-1212 → 5175551212
• 1.517.555.1212 → 5175551212

For types TWT, IGR, SNP, YTB, TOK, TCH, and DCR the prefixed at-sign ("@") should be stripped if if exists. For example:

• @domainfox → domainfox
• @BadApple → badapple
• SolidAlchemy → solidalchemy

The salt is appended to the end of the entry. Section 3 in this document provides information on how to interact with the Registry Compliance system in order to obtain the most recent version of salt. Salts are at least 128 characters long, and may contain up to 180 characters. Within this range, however, do not rely on the salt's length to remain constant over time. Salts may contain non-alphanumeric characters, including any ASCII symbol. Salts are passed from the Registry Compliance systems in a URL-encoded format (see RFC 1738) and should be URL-decoded before use. Detailed instructions for receiving and decoding salts appear in Section 3 of this document.

Only the entry's case should be lowered. Ensure you do not strip characters or change the case of the pre-pended type or appended salt before hashing. There is no delimiter between the type, the entry, and the salt. The salt will vary in length and will rotate at a random interval over time.

Please note: two salts are returned by the Registry Compliance system ("salta" and "saltb"). When formatting your list for upload to the system, you should append "salta" to the contact points you are uploading. The second salt ("saltb") is used when results are returned.

Two examples are provided below.

If you choose to transmit binary data, you may wish to hash each entry into HEX for storage in your system, but convert it to binary during transmission. Alternately, you may generate both binary and HEX versions of each entry, retaining the HEX version until you receive the returned results. In either case, you should map each HEX MD5 hash to its associated entry in order to do a reverse comparison when results are returned.

Your MD5 function should output a 16-byte binary result, regardless of the length of the contact point or the appended current salt value. Binary hash output should then be appended to a file. It is critical that this file be in binary format. Typically you can configure your MD5 function to generate binary rather than HEX. Alternatively, you may output HEX and then convert the file to binary. Converting from HEX may be preferable since you will need a HEX version of the MD5 hash for your final results comparison, described in Section 4 of this document.

If you do a conversion from HEX to binary there is a special consideration on some Windows-based machines. If your MD5 function generates uppercase HEX, you should convert those characters to lowercase before the binary conversion. We have found this resolves a number of problems when converting HEX. Always when converting from a non-binary format, ensure that the conversion is done byte-wise with the high-nibble first.

A file of hashed entries should be prepared for transmission to the Registry Compliance system. If you are checking multiple types of entries, each file must contain only one type. In other words, you may not mix hashes of e-mail addresses with hashes of Yahoo Instant Messenger Ids.

The hashed entries file should be stored in HEX format, but may be transmitted to the system in either binary or HEX. Binary transmission, however, is preferred, since binary data is half the size of HEX data. When transmitting entries to the system, they should be simply appended, one after the other, with no delimiter. Since all hashed entries are a common number of bytes (16 for binary or 32 for HEX), the individual entries can be subdivided, even without a delimeter, once the file is uploaded. No carriage returns, line breaks, or other extraneous characters should be inserted into the file. Binary files should be byte-wise with the high-nibble first. The actual name of the file does not matter.

Each file can contain a maximum of 2.5 million entries, or approximately 40 megabytes. Attempting to upload a single file exceeding 40 megabytes will trigger an abuse event, which may restrict your access to the system. If the list that you are checking exceeds 2.5 million entries, you may upload multiple files under a single "check task" job. However, the files should be split in such a way that the file size is divisible by 16 bytes for binary files or 32 bytes for HEX files. In other words, you should not split a hashed entry into more than one file. Section 3 in this document describes the process of associating multiple files with a single task for lists exceeding 2.5 million entries.

In order to accommodate domain-wide registrations on the Children's Protection Registries, certain considerations are in place for e-mail addresses. Because it is impossible to know the original e-mail addresses from the uploaded hash file, and therefore impossible to determine the domains associated with those e-mail addresses, a separate file of hashed domains must also be uploaded and associated under the same task.

Domains should be converted to lower case before they are hashed. Each domain should be included on the domain list only once, even if it is shared by multiple e-mail addresses. Based on current government regulations, when a list of domains is run in conjunction with a list of e-mail addresses, there is no per-check charge for checking the associated domains.

Domains should be hashed using the type DMN. See the example below:

In order to ensure that the file is formatted correctly and no errors are introduced during transmission, we implement two checking systems: a verification entry and a file checksum.

The first entry in each file must be a special verification hash entry. This verification hash entry varies for each file type. The entries to create this verification hash are below:

• EML - VeriEntry@RegistryCompliance.net
• DMN - RegistryCompliance.net
• FAX - 8884867726
• SMS - 8884867726
• TWT - @VeriRegistryCompliance
• IGR - @VeriRegistryCompliance
• SNP - @VeriRegistryCompliance
• YTB - @VeriRegistryCompliance
• TOK - @VeriRegistryCompliance
• TCH - @VeriRegistryCompliance
• DCR - @VeriRegistryCompliance

You should hash each of the entries above just as you would hash any other entry on your list. Since the intent of this check is to ensure that your hashing function is working correctly, you should run the entries above through the same function as you do for any other entry on your list. The verification entries above are intentionally formatted in such a way as to test that you are properly reformatting them (for example, they include uppercase letters).

If you upload multiple files as part of a single task, you must include a verification entry at the beginning of each file. This is true even if you attach multiple files containing the same type of entry within a single task.

In addition to the verification check, you must generate a checksum of the entire file. To do that, you should use MD5 to hash the entire file. You should either setup the MD5 function to output HEX, or convert the binary output to HEX. This HEX hash code functions as a checksum and you include it with the file during upload. Instructions on how this checksum should be passed with your upload request are discussed at length in Section 3 of this document. The Registry Compliance system generates its own MD5 checksum of the file upon receipt. If these two checksums do not match, then an error condition is returned. This ensures that the file you upload is not corrupted during transmission.

Every operation request from a client application to the Registry Compliance system is accomplished as a POST request through the HTTPS protocol. For more information on passing form data via POST requests, including transferring files, see RFC 1867. Below is an example of a complete POST request for the "TASK_ADD" operation (defined in section 3.2.3). This operation is one of the more complicated tasks an application will need to initiate with the server. Generally, all POST requests will follow this basic format with modifications for their particular requirements. Libraries that handle POST requests, such as LWP in Perl, will automatically generate such a request with the data you provide.

• POST /serve.html HTTP/1.1
  Host: [access IP address]
  User-Agent: RegistryComplianceAPIAccess
  Content-Type: multipart/form-data; boundary=aAaAbBbBcCcCdDdD [app-defined boundary text]
  Content-Length: [length of POST in bytes]
  Connection: close
  Cache-Control: no-cache
  
  --aAaAbBbBcCcCdDdD [app-defined boundary text]
  Content-Disposition: form-data; name="request_params"
  
  api_key=[96 characters]&op=TASK_ADD&account_key=[64 characters]&data_type=EML&data_size=[file size in bytes]&data_checksum=[32 characters]&task_key=[32 characters]
  --aAaAbBbBcCcCdDdD [app-defined boundary text]
  Content-Disposition: form-data; name="datafile"; filename="datafile"
  Content-Type: application/octet-stream
  
  [binary data]
  --aAaAbBbBcCcCdDdD [app-defined boundary text]--
  

Some libraries allow you to specify the multi-part boundary, while others will set this boundary for you. This "app-defined boundary text" can be any text which delimits the boundary between parts in the POST request. Because for some requests you will be passing a substantial portion of hashed data, which is generally random, you should choose a boundary which is relatively long (at least 50 characters) and unlikely to appear at random within even several megabytes worth of hashes. For more information on choosing a boundary, see RFC 1867.

We have included simple code samples, written in common languages, to assist you in developing your POST functionality. Please click the link below that corresponds to your development platform:

• Windows C#
• PHP

All operations return an XML response to indicate whether the POST was completed successfully. They furthermore include a timestamp for the operation and a transaction code to uniquely identify the particular operation. Most tasks also return additional data such as a task ID, the status of a current task, etc. At a minimum, successful server requests will return at least the following:

In the REQUEST portion of the XML response, the "OP" code is echoed back in order to help you keep track of which operation obtained the returned result. If a request has an associated "task key", then that information is also echoed as part of the REQUEST portion of the XML response. While the basic hierarchical structure of each XML response will be as they appear in the examples in this document, you should not rely on the order of the XML results to be identical to the examples that appear here.

Within the RESPONSE portion of the XML, the TIMESTAMP indicates the local Registry Compliance server time in RFC 822 format. The TRANSACTION field uniquely identifies the particular transaction with a 35-character string and should be reported to the Registry Compliance Customer Support Staff if a particular transaction needs to be audited. The ISTEST field will only be present if you are querying against one of the test servers. If operations are submitted to these servers, information regarding the connection to that server will be contained in this field. Additional information will also be returned for successful requests, depending on the operation. These additional XML fields are described under the various "OP" codes described in Section 3.2 of this document.

Unsuccessful requests will return the following:

Specific ERRCODEs are always 3 digit numbers. ERRMSGs contain an explanation of the error that was encountered and what can be done to remedy it. For an explanation of the specific ERRCODEs and ERRMSGs, see Section 5 of this document.

Every POST request must include at least the following three basic parameters:

• "api_key"
  

  Senders and ESPs who have been approved for access to the API are issued an API key. API keys are 96 characters in length and are issued only to senders and ESPs who have been approved for access to the API. API keys are also associated with a particular set of IP addresses. Requests using a particular API key may only be initiated from one of the associated IP addresses. API-approved senders and ESPs may list the IP addresses they would like to access the API from when applying for access to the API.

• "account_key"
  

  In addition to the API key, every request must be associated with a particular account key. To receive an account key, governments require each individual or company accessing the API to submit certain basic information. For more information, see the Registry Compliance website.

• "op"
  

  To define which request is being made, the client should POST an "OP" code. "OP" codes are used to retrieve the current salts, begin a new task, add files to a task, begin the scrubbing process on a task, retrieve the results from a task, or cancel a task that has been started. Depending on the particular request, additional parameters may also be required. Specific "OP" codes are described in Section 3.2 below.

Because certain operations must be multipart form data posts, under the specifications of RFC 1867 each field in the POST request must be listed in a separate part. This can be tedious to code if you are using certain less-friendly libraries to accomplish your POST request or, especially, if you are using raw sockets. To provide a shortcut, we allow all the required request fields to be passed in a single, optional parameter: "request_params".

• "request_params" (optional shortcut)
  

  When using "request_params" to submit multiple variables via a single parameter, each variable should be formatted as if it were being posted through a URL GET request (see RFC 1738). In other words, it should consist of the variable name, followed by an equals sign, followed by the value of the variable. Multiple variable/value pairs should be separated by ampersands. All data should be URL-encoded to avoid potential transmission errors (see RFC 1738). The order of the individual variables in the "request_params" field does not matter. See the following example for the "TASK_ADD" operation:

  • api_key=[96 characters]&op=TASK_ADD&account_key=[64 characters]&task_key=[32 characters]&data_type=EML&data_size=[file size in bytes]&data_checksum=[32 characters]

  Any file data must still be passed in a second part (see, for example, the "TASK_ADD" operation described below). However, using this shortcut limits the total number of parts of a POST request to a maximum of two. You do not have to use the "request_params" field if the library you are using makes it easy to post each field required for a task individually.

If you elect to submit multiple parameters, rather than using "request_params", the order of the parameters included in the POST does not matter. You should not submit "request_params" if you submit individual parameters. If you do so, "request_params" will take priority. Please use one method or the other to submit parameters. To avoid confusion, do not mix both in a single operation.

Interaction with the Registry Compliance system is accomplished through the use of various operations. These operations are commenced with predefined "OP" codes. These "OP" codes are passed via the OP parameter as part of the POST request. The currently supported "OP" codes are listed in the following subsections, along with descriptions of each code's purpose.

This "OP" code is sent in order to get the current salts used for hashing addresses. It does not need to be run before every transaction, but should be run if the "TASK_START" operation returns a result that the client application is currently using expired salts. This allows an API user to store a hashed version of a sender's list without having to rehash existing entries until the salt rotates.

This "OP" code is sent to begin a new scrubbing task. Each task may contain more than one file, and while each file must contain only a single type of entry, each task can scrub multiple files of different types at once. Once a new task is started, you will receive a task key. Most other "OP" codes, such as those used to upload files or cancel a task, require this task key. It should be retained by the client application at least until the task is complete.

This "OP" code is sent to add a file of hashed entries to a particular task. These are the entries to be scrubbed. More than one file may be added to each task. Each file must only contain a single type of entry, however files of different types may be attached to a single task. For example, one task may scrub e-mail addresses, domains, and Yahoo instant messenger IDs, but the task must have a minimum of three files associated with it (one for each type).

Attached files must follow the specifications described in Section 2 of this document. Specifically, they should be byte-wise binary files with the high-nibble first. Each file should be hashed using MD5. The results of the file's MD5 hash should be retained in HEX format as a checksum. This checksum is passed along with the "TASK_ADD" operation.

The file itself should be attached to the post as an HTTPS multipart-form data post (for more information, see RFC 1867). Files must not exceed 40 megabytes. We suggest you limit each file to 2.5 million entries for binary files or 1.25 million entries for HEX files, to remain under this cap. If you need to scrub more than this, you may attach multiple files to a single task. All files attached to a single task will be scrubbed as if they were one request and the results will be returned together.

It is important to store the TASK_ADD_DOMAIN value that is returned as part of the "TASK_START" operation results. All file upload POST operations MUST post to this domain.

Please note that the scrubbing process does not begin until all the files have been uploaded and you submit a "TASK_COMMIT" operation.

After all files are uploaded and associated with a particular task, you need to run a "TASK_COMMMIT" operation to begin the scrubbing process. This operation ensures that everything is correctly formatted and computes the estimated cost necessary to complete the scrubbing process for this task.

You may obtain a list of your currently open tasks by using this operation. You may also obtain a list of your tasks, regardless of whether they are open or not, if they have been run in the last seven days. Open tasks are defined as tasks for which a "TASK_START" operation has been submitted, but for which the server has not received a "TASK_COMMIT" request.

You may cancel a task at any time. If a task is cancelled it will be closed and no longer open for file uploading or scrub processing. You cannot reactivate a task after it has been cancelled. Uncommitted tasks are automatically cancelled one week after they are first started. Completed tasks that have not been downloaded are automatically cancelled, without the account being billed, 30 days after the task was first started.

To check the status of a task, you may submit a "TASK_CHECK" operation. If the task is complete, the "TASK_CHECK" operation will provide a final cost to complete the scrubbing operation. If the associated account has sufficient funds, the "TASK_CHECK" operation will also provide a code for retrieving the results file. Retrieving the file will charge the given amount from the account associated with the task. If insufficient funds are available, the "TASK_CHECK" operation will provide instructions on how to deposit the requisite funds to complete the task. Section 4 in this document describes in detail how to handle the results file.

The "TASK_CHECK" operation will also return the status of a task if it is not yet complete. Assuming the task has been committed but not completed, the operation will include updated estimates on the time before the task will be complete. If the task is not yet committed, the operation will return its current status as well as additional information about the task.

After a task is complete, you will be issued a result key through the "TASK_CHECK" function. You can use this result key to retrieve the match results.

The task's user account will be charged the total amount for the scrubbing task the first time you access the task results with the result key. You may subsequently access the results after initial download without being charged.

After a task is complete, you will be provided with a result key for your match file through the "TASK_CHECK" operation. To retrieve the results of your scrub process, issue the "TASK_RESULTS" operation described in Section 3.2.8 of this document. The results of your scrub process for all jurisdictions and all types are returned in a single XML document. The XML document also includes report information for the particular task. The XML document will remain online and retrievable via the "TASK_RESULTS" process for at least 30 days after you initially began the task that created it.

Accessing of the results document via "TASK_RESULTS" is limited to the approved IP addresses of the API access key associated with the task. The task's account will be deducted the cost of the scrub when you access the results via the "TASK_RESULTS" operation. This cost was reported exactly via the "TASK_CHECK" operation through which you received the URL to download the file. If insufficient funds are in the account at the time of an attempted file download, you will receive an error.

In addition to the REQUEST section, there are three major sections of the XML results document: SCRUB_REPORT, SCRUB_RESULTS, POSSIBLE_SCRUB_EXCEPTIONS.

Each results document will include a transaction report section. This file will include XML with details on the transaction you submitted. The XML transaction details may include the fields in the example below:

Particular license restrictions on how the results data may be used may be included as part of this document. Specifically, these licenses limit your storing, transferring, reverse engineering, or using these files for any purpose other than removing the entries they represent from a particular client's list. Links to these license terms are included in the document, and you must have agreed to these terms prior to accessing the scrubbing mechanism.

To ensure compliance with each jurisdiction's law, the next scrub of the entries that remain on the list after the current scrub must take place before the GOOD_UNTIL date listed for each jurisdiction.

The Match Results Section of the document describes the "matched" entries that must be removed from a sender's list in order to be in compliance with the law. The matches are divided by jurisdiction. Each jurisdiction is then divided by type. If multiple types were scrubbed at one time, then they will be listed one after another. You are required, under the law, to remove any results listed in this section unless there is a domain exception, as described in Section 4.3 below.

Two MD5 hashes in HEX format are returned for each match. The SALTA match is the same as the hashed entry that you submitted to be scrubbed, however it is in HEX, not binary, format. It is created using an MD5 function of the following format:

• MD5_HEX([type][entry][SALTA])

A second MD5 HEX hash code, SALTB, is provided as a double-check. This eliminates the already-unlikely chance that a "collision" could result in an entry being removed that is not in fact a match.

To use the double-check mechanism, you should scan your list for any entries that match any of the SALTA_MATCH fields. Once found, you should use an MD5 HEX hash function to rehash the plain-text entry using the SALTB value. This function should look like:

• MD5_HEX([type][entry][SALTB])

See the following example:

Under the laws, you must remove any entries from your originally uploaded list that match both the SALTA_MATCH and the SALTB_MATCH, unless a domain exception is listed later in "Match Possible Exceptions" section of the document, as explained in Section 4.3 of this document. Continuing to send messages to any matched and verified entry (verified using the SALTB hash) is a violation of the law. You may not store or share the results you receive through the scrubbing process with any party other than the client for which the scrubbing was done. Storing the results or sharing them beyond the client may constitute a felony, punishable by up to 3 years in jail depending on the jurisdiction. Please ensure when constructing your application that you do not violate these storage or sharing provisions of the law. For more information on these requirements, see:

• Michigan Compliance Information
• Utah Compliance Information

If there were no matches for a particular jurisdiction and type then the NUM_MATCHES_FOR_THIS_TYPE field will contain a "0" (zero) and will not be followed by a <RETURNED_MATCHES> section. If you receive a completely empty file, or if you receive no results file, then an error has occurred.

For domain entry types (DMN), you must remove all e-mail addresses that are created with a matched domain. This requires you to not only map the SALTA_MATCH and SALTB_MATCH back to a particular domain, but to also associate that plain-text domain with any e-mail addresses constructed with it that appear on your list. The legal effect of a domain appearing as a match is the same as if all the e-mail addresses on an uploaded list constructed with that domain were returned as matches.

In certain cases, there will be exceptions from the matched entries that appeared above. At this time, the only case in which this may occur is if a domain was matched but a particular e-mail address under that domain was exempted from coverage. Although exceptions are likely to be rare, you should still construct your systems to accommodate them.

Any exception listed in this section of the document trumps any listing that appears in the SCRUB_RESULTS section. In other words, exceptions may remain on an uploaded list even if there was an indication of a match in the Scrub Results section.

Exceptions will be presented in the following XML format:

Just like matches, exceptions are returned as MD5 HEX hashes, formed with both SALTA and SALTB. Only if an entry on a list hashes to both the SALTA_EXCEPTION and the SALTB_EXCEPTION values may you continue to include it on your list.

Please be aware that just because exceptions appear in this section does not mean they will appear on your list. For example, domain owners may list exceptions for any registered domain. If a registered domain matches an entry on your list, then you will be receive the complete list of exceptions for that domain, even if none ever appeared on your list. This means there does not need to be any correlation between the listed exceptions and the entries on your scrubbed list. Typically, even if exceptions are listed in the POSSIBLE_SCRUB_EXCEPTIONS section, they will not appear anywhere on your scrubbed lists.

As with any other data returned from the Registry Compliance system, you may not share, distribute, store, or attempt to decompile any of the returned exceptions except as necessary to comply with the law. Doing so may constitute a felony under the law. For the specific law requirements, please visit

• Michigan Compliance Information
• Utah Compliance Information

You may encounter error codes when running a transaction. These codes are all formatted as a 3-digit number. The first digit determines the general class of the code:

• 1##: Error occurred during REQUEST validation
• 2##: Error related to TASK validation
• 4##: Error occurred related to the system's TaskCache File
• 5##: Abuse related errors
• 9##: System related errors

In section 5.2 of this document, the specific error codes are outlined. Accompanying each error code is a description of the error. Applications designed to interface with the Registry Compliance API should be aware of these errors and tested to ensure they can respond appropriately.