CloudFlare Hosting Provider API Version 1.1.1

Copyright © 2012 CloudFlare, Inc. All rights reserved.

1 - Overview

This document explains in detail the semantics of the function calls you can make using the Hosting Provider API service. This service is limited to access by web hosting providers who have agreed to the required license terms.

In this document, you will learn:

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

https://www.cloudflare.com/docs/host-api.html

The Client Interface API document is maintained at:

https://www.cloudflare.com/docs/client-api.html

If you have comments, find errors, or have questions, please contact .

1.1 - Interaction with the CloudFlare System

Interaction with the CloudFlare 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:

1.2 - General Issues Checklist

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.

1.3 - Getting Setup Quickly

At a minimum, host providers should implement the user_create (Section 3.2.1) and zone_set (Section 3.2.2) operations. Hosting providers also need to implement a way to update their DNS records to point any subdomains setup with CloudFlare to the appropriate forward_tos address.

2 - Client Operations

Every operation request from a client application to the CloudFlare system is accomplished as a POST request through the HTTPS protocol. For more information on passing form data via POST requests, see RFC 1867.

All POSTs should be directed at the host provider gateway interface, located at:

https://api.cloudflare.com/host-gw.html

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:

All operations return a JSON response to indicate whether the POST was completed successfully. In the REQUEST portion of the JSON response, the "act" parameter is echoed back in order to help you keep track of which operation obtained the returned result.

Unsuccessful requests will return an error code as well as an error message. The error message is suitably formatted to be displayed to an end user of the application interfacing with the API. Here is an example:

{ }

The err_code is always a 3 digit numbers. The msg will contain an explanation of the error that was encountered. The msg parameter will be suitably formatted to be displayed to an end user of the application interfacing with the API. For an explanation of the specific error codes, see Section 4 of this document.

Successful requests may also include a msg. If present, the message will be suitably formatted to be displayed to an end user. If no msg is present the parameter will be set to null. In all cases, the msg parameter will be an ASCII string not longer than 1,000 characters.

3.1 - Basic Parameters

Every POST request must include at the following basic parameter(s):

3.2 - Specific Host Provider Operations

Interaction with the CloudFlare system is accomplished through the use of various operations. These operations are commenced with predefined "act" or action parameters. These actions are specified via the act parameter as part of the POST request. The currently supported actions are listed in the following subsections, along with descriptions of each action's purpose.

At a minimum, hosting providers should support the user_create and zone_set actions, as described in Section 3.2.1 and 3.2.2 respectively. Additional actions may be supported in order to make your application more full featured for your users.

3.2.1 - "user_create" - Create a CloudFlare account mapped to your user (required)

This act parameter is used to create a new CloudFlare account on behalf of one of your users. If you know that your User already has an existing account with CloudFlare, use the "user_auth" operation, described in Section 3.2.2, instead. For your convenience, CloudFlare will automatically perform a "user_auth" operation (Section 3.2.2) if the CloudFlare account already exists.

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "cloudflare_email"

    The User's e-mail address for the new CloudFlare account.

  • "cloudflare_pass"

    The User's password for the new CloudFlare account. CloudFlare will never store this password in clear text.

  • "cloudflare_username" (optional)

    The User's username for the new CloudFlare account. CloudFlare will auto-generate one if it is not specified.

  • "unique_id" (optional)

    Set a unique string identifying the User. This identifier will serve as an alias to the user's CloudFlare account. Typically you would set this value to the unique ID in your system (e.g., the internal customer number or username stored in your own system). This parameter can be used to retrieve a user_key when it is required. The unique_id must be an ASCII string with a maximum length of 100 characters.

  • "clobber_unique_id" (optional)

    Any operations that can set a unique_id can be set to automatically "clobber" or unset a previously assigned unique_id.

Here is an example POST to the user_create action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=user_create' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'cloudflare_email=[email protected]' \
  -d 'cloudflare_pass=newpassword' \
  -d 'unique_id=someuniqueid'

Output:

If the information to create a new CloudFlare user account is valid and no errors occur, the "user_create" action will echo the request and return a user_key. A user_key is a string of ASCII characters with a maximum length of 32 characters.

Important: If no unique_id is specified, the user_key should be stored in your system. Certain actions to modify the new user's setup, such as user_lookup or zone_set, will require the user_key. If you have specified a unique_id (e.g., the internal customer number or username stored in your own system) then you can always use that to retrieve the user_key. You should be able to lookup from your own system the user_key, the unique_id, or both.

Here is a successful JSON response to the POST described in the INPUT section above:

{
  • -
    request: {
    • act: "user_create"
    },
  • -
    response: {
    • cloudflare_email: "[email protected]",
    • user_key: "8afbe6dea02407989af4dd4c97bb6e25",
    • unique_id: "someuniqueid",
    • cloudflare_username: "newuser23"
    },
  • result: "success",
  • msg: "Your new CloudFlare account was created, you can login at www.cloudflare.com with the email address ([email protected]) and password."
}

The cloudflare_pass field will never be echoed back. If there is no msg returned, that parameter will be set to NULL.


3.2.2 - "zone_set" - Setup a User's zone for CNAME hosting (required)

This act parameter is used to set up CNAME record hosting for a User's zone. The user_key is required. If you do not have the user_key on hand, perform a "user_lookup" (see Section 3.2.3).

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "user_key"

    The unique 32 hex character auth string, identifying the user's CloudFlare Account. Generated from a user_create (Section 3.2.1) or user_auth (Section 3.2.2).

  • "zone_name"

    The zone you'd like to run CNAMES through CloudFlare for, e.g. "example.com".

  • "resolve_to"

    The CNAME that CloudFlare should ultimately resolve web connections to after they have been filtered, e.g. "resolve-to-cloudflare.example.com". This record should ultimately resolve to the one or more IP addresses of the hosts for the particular website for all the specified subdomains. Note: it CANNOT be the naked zone name, in this case example.com

  • "subdomains"

    A comma-separated string of subdomain(s) that CloudFlare should host, e.g. "www,blog,forums" or "www.example.com,blog.example.com,forums.example.com".

Here is an example POST to the zone_set action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=zone_set' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'user_key=57bd6ab7536daa87cab966ad723f014a' \
  -d 'zone_name=someexample.com' \
  -d 'resolve_to=cloudflare-resolve-to.someexample.com' \
  -d 'subdomains=www,blog,wordpress:cloudflare-rs2.someexample.com'

If run, the intent of the above action would be to configure the CloudFlare system such that it would accept traffic to www.someexample.com and blog.someexample.com. After having been routed through the CloudFlare network, if the traffic is clean and cannot be handled by the CloudFlare cache, it will be relayed to cloudflare-resolve-to.someexample.com. Traffic to another subdomain (e.g., forum.someexample.com) would not be setup to run through CloudFlare.

Note: The zone_set action replaces any previous setup for the particular zone_name. If are adding an additional subdomain to an account that already has some subdomains setup, you should specify all the subdomains not only the new subdomains.

Note: The wordpress subdomain above is configured to be relayed to the CNAME cloudflare-rs2.someexample.com, rather than the default cloudflare-resolve-to.someexample.com.


Output:

If the information to setup a zone is valid and no errors occur, the "zone_set" action will return the zone_name (string), resolving_to (string), hosted_cnames (map), and forward_tos (map) as confirmation. The forward_tos will be in the format of the fully qualified domain plus cdn.cloudflare.net (e.g., www.example.com.cdn.cloudflare.net or blog.example.com.cdn.cloudflare.net) .

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "zone_set"
    },
  • -
    response: {
    • zone_name: "someexample.com",
    • resolving_to: "cloudflare-resolve-to.someexample.com",
    • -
      hosted_cnames: {
      • www.someexample.com: "cloudflare-resolve-to.someexample.com",
      • blog.someexample.com: "cloudflare-resolve-to.someexample.com",
      • wordpress.someexample.com: "cloudflare-rs2.someexample.com"
      },
    • -
      forward_tos: {
      • www.someexample.com: "www.someexample.com.cdn.cloudflare.net",
      • blog.someexample.com: "blog.someexample.com.cdn.cloudflare.net",
      • wordpress.someexample.com: "wordpress.someexample.com.cdn.cloudflare.net"
      }
    },
  • result: "success",
  • msg: null
}

Important: To complete setup for your user, you should automatically update your user's DNS settings to resolve the subdomains specified in zone_set or zone_lookup to the corresponding forward_tos. Until you complete this step, traffic will not be routed through the CloudFlare system. For your DNS settings, we recommend a TTL for the record of not less than 900 seconds. You should setup your user's DNS records for each subdomain to mirror the following results:

;; ANSWER SECTION:
www.someexample.com.    900 IN   CNAME  www.someexample.com.cdn.cloudflare.net.

3.2.3 - "user_lookup" - Lookup a user's CloudFlare account information (optional)

This act parameter is used to lookup information about a User's existing CloudFlare account. This action is typically used to check if the account exists or to retrieve a user_key. You do not need to support this function if you plan to store the user_key on your system.

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "cloudflare_email" or "unique_id"

    Lookup a user's account information or status by either cloudflare_email or unique_id.

Here is an example POST to the user_lookup action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=user_lookup' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'unique_id=someuniqueid'

Output:

If the information to lookup the status of a CloudFlare account is valid and no errors occur, the "user_lookup" action will return the user_key (string), user_exists (boolean), user_authed (boolean), cloudflare_email (string), unique_id (string), and hosted_zones (array).

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "user_lookup"
    • unique_id: "someuniqueid"
    }
  • -
    response: {
    • user_exists: true
    • cloudflare_email: "[email protected]"
    • user_authed: true
    • user_key: "8afbe6dea02407989af4dd4c97bb6e25"
    • unique_id: "someuniqueid"
    • -
      hosted_zones: [
      • "someexample.com"
      ]
    }
  • result: "success"
  • msg: null
}

The hosted_zones array lists all the zones that you are registered as hosting.


3.2.4 - "user_auth" - Authorize access to a user's existing CloudFlare account (optional)

This act parameter is used to gain access to a User's existing CloudFlare account. This action is automatically called by "user_create" (Section 3.2.1) if the CloudFlare account already exists. In most cases, when setting up an account, you should use user_create unless you know a user already has a CloudFlare account.

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "cloudflare_email"

    The User's e-mail address for the new CloudFlare account.

  • "cloudflare_pass"

    The User's password for the new CloudFlare account. CloudFlare will never store this password in clear text.

  • "unique_id" (optional)

    Set a unique string identifying the User. This identifier will serve as an alias to the user's CloudFlare account. Typically you would set this value to the unique ID in your system. This parameter can be used as an alias for other actions (e.g., it can substitute for the cloudflare_email and cloudflare_password if you choose not to store those fields in your system).

  • "clobber_unique_id" (optional)

    Any operations that can set a unique_id can be set to automatically "clobber" or unset a previously assigned unique_id.

Here is an example POST to the user_auth action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=user_auth' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'cloudflare_email=[email protected]' \
  -d 'cloudflare_pass=newpassword' \
  -d 'unique_id=someuniqueid'

Output:

If the information to auth a new CloudFlare user account is valid and no errors occur, the "user_auth" action will return a user_key. If no unique_id is specified, the user_key should be stored in your system. Certain actions, such as user_lookup or zone_set require the user_key.

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "user_auth"
    },
  • -
    response: {
    • cloudflare_email: "[email protected]",
    • user_key: "8afbe6dea02407989af4dd4c97bb6e25",
    • unique_id: "someuniqueid"
    },
  • result: "success",
  • msg: null
}

3.2.5 - "zone_lookup" - lookup a specific user's zone (optional)

This act parameter is used to lookup information about a User's zone in the CloudFlare system. This action is typically used to check if the zone exists (zone_exits is true) or if you register as the host (zone_hosted is true).

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "zone_name"

    The zone you'd like to lookup, e.g. "example.com".

Here is an example POST to the zone_lookup action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=zone_lookup' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'user_key=57bd6ab7536daa87cab966ad723f014a' \
  -d 'zone_name=someexample.com'

Output:

If the information to lookup the status of a CloudFlare account is valid and no errors occur, the "zone_lookup" action will return the zone_name (string), zones_exists (boolean), zone_hosted (boolean), hosted_cnames (map), and forward_tos (map).

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "zone_lookup"
    }
  • -
    response: {
    • zone_name: "someexample.com"
    • zone_exists: true
    • zone_hosted: true
    • -
      hosted_cnames: {
      • someexample.com: "cloudflare-resolve-to.someexample.com"
      • blog.someexample.com: "cloudflare-resolve-to.someexample.com"
      • www.someexample.com: "cloudflare-resolve-to.someexample.com"
      }
    • -
      forward_tos: {
      • someexample.com: "someexample.com.cdn.cloudflare.net"
      • blog.someexample.com: "blog.someexample.com.cdn.cloudflare.net"
      • www.someexample.com: "www.someexample.com.cdn.cloudflare.net"
      }
    • ssl_status: "ready"
    • ssl_meta_tag: "<meta name="globalsign-domain-verification" content="adCaeN_AB75flaIxkXya-33kvfDSoEW8222a-b12ce" />"
    • sub_label: AWESOMEHOST_PLAN_PLUS
    • sub_status: V
    }
  • result: "success"
  • msg: null
}

The following describes specific statuses of certain elements on the response.

  • "ssl_status"

    This status will be set to "ready" when the zone's SSL certificate has been activated on CloudFlare.

  • "ssl_meta_tag"

    The SSL META tag needs to be inserted in the HEAD of the index page of the zone in order for the SSL certificate to be issued.

  • "sub_label"

    This subscription label will be set to a reseller specific value used to identify the zone's subscription.

  • "sub_status"

    The subscription status value will be "V" for active and "D" for deleted.


3.2.6 - "zone_delete" - delete a specific zone on behalf of a user (optional)

This act parameter is used to delete a User's previously "zone_set" zone in the CloudFlare system. CloudFlare will stop honoring DNS requests for deleted zones after a short period of time. Be sure to unset all CloudFlare forwarded CNAMEs prior to or immediately after a "zone_delete".

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

  • "zone_name"

    The zone you'd like to lookup, e.g. "example.com".

Here is an example POST to the zone_delete action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=zone_delete' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'user_key=57bd6ab7536daa87cab966ad723f014a' \
  -d 'zone_name=someexample.com'

Output:

If the information to lookup the status of a CloudFlare account is valid and no errors occur, the "zone_delete" action will return a success zone_name (string), zone_deleted (boolean).

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "zone_delete"
    }
  • -
    response: {
    • zone_name: "someexample.com"
    • zone_deleted: true
    }
  • result: "success",
  • msg: null
}

3.2.8 - "host_key_regen" - Regenerate your host key(optional)

This act parameter is used to change a host key for a CloudFlare host provider account.

Input:

Requires the basic parameters described in Section 3.1 of this document. In addition, you must pass the following parameters via the POST request.

Here is an example POST to the host_key_regen action:

curl https://api.cloudflare.com/host-gw.html \
-d 'act=host_key_regen' \
-d 'host_key=aecogk1c19f0e6058afc8e0c067abcfb'

Output:

If the information to regenerate a new host key for the CloudFlare host provider account is valid and no errors occur, the "host_key_regen" action will echo the request and return the newly generated host_key. Thehost_key is a string of ASCII characters with a maximum length of 32 characters.

Here is a successful JSON response to the POST described in the INPUT section above:

{
  • -
    request: {
    • act: "host_key_regen",
    • host:key: {
      • __host_key: "3cbc08d1907cd47627df5048f7f2600c"
    • }
    },
  • result: "success",
  • msg: "null"
}

If there is no msg returned, that parameter will be set to NULL.


3.2.10 - "zone_list" - List the domains currently active on CloudFlare for the given host (optional)

This act parameter is used to request the complete list of domains which CloudFlare believes is active for your host. The limit, offset, zone_name, sub_id, zone_status, and sub_status parameters are all optional. They default to 100, 0, NULL and NULL respectively. The sub_id applies to CloudFlare Resellers only. The zone_status parameter has valid values of V,D,ALL, where V shows active zones only, D deleted, and ALL all. The sub_status parameter has valid values of V,CNL,ALL, where V shows zones with an active subscription only, CNL canceled, and ALL all.

Input:

Requires the basic parameters described in Section 3.1 of this document.

Here is an example POST to the zone_list action:

curl https://api.cloudflare.com/host-gw.html \
  -d 'act=zone_list' \
  -d 'host_key=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'limit=10' \
  -d 'offset=0'\
  -d 'zone_name=example.com' \
  -d 'sub_id=1023' \
  -d 'zone_status=ALL'
  -d 'sub_status=ALL'

Output:

If the information to lookup the status of a CloudFlare account is valid and no errors occur, the "zone_list" action will return a list of zones.

A successful response to the POST from the INPUT section above:

{
  • -
    request: {
    • act: "zone_list"
    }
  • -
    response: [{
    • sub_id: 17
    • zone_id: 1
    • sub_activated_on: "2011-11-23 17:58:56.791516-05"
    • sub_status: "V"
    • sub_expired_on: undef
    • sub_label: "CF_RESELLER_PRO"
    • zone_name: example.com
    • user_email: [email protected]
    • zone_status: 'V'
    }],
  • result: "success",
  • msg: null

Zone status codes are

  • V: Active
  • D: Deleted
Subscription status codes are
  • V: Active
  • CNL: Canceled

Note: subscriptions are per zone. If a zone does not have a subscription, the subscription information will be null.

4 - Error Feedback and Codes

You may encounter error codes when running a transaction. These codes are all formatted as a 3-digit number.

In addition to the error code, a msg parameter will be included for every error. This msg parameter is formatted appropriately to be displayed to the end user.

4.1 - Responding to Error Conditions

In section 4.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 CloudFlare API should be aware of these errors and tested to ensure they can respond appropriately. The error messages can safely be relayed to the end user.

4.2 - Error Codes

Error code 100: No or invalid host_key.

Error code 101: No or invalid act.

Error code 103: Please provide a CloudFlare e-mail address.

Error code 104: Invalid unique_id. Allowed character set is '-_a-z0-9#@+.,'.

Error code 105: Invalid unique_id. Max size exceeed.

Error code 106: Invalid clobber_unique_id. Must be 0 or 1.

Error code 107: That action requires either 'cloudflare_email' or 'unique_id' to be defined.

Error code 108: Please provide a CloudFlare password.

Error code 109: CloudFlare password is too obvious.

Error code 110: Your CloudFlare password must be at least 6 characters.

Error code 111: Please provide a CloudFlare username.

Error code 112: Please provide a CloudFlare username of at least 3 characters.

Error code 113: CloudFlare usernames must consist of letters and numbers. Delineation using . - or _ characters is allowed. You entered "[$cloudflare_username]".

Error code 114: That CloudFlare username is too close to a disallowed name. You entered "[$cloudflare_username]".

Error code 115: No user_key.

Error code 116: Invalid user_key.

Error code 117: The unique_id '[$unique_id]' has already been assigned to a different user.

Error code 118: CloudFlare account "[$cloudflare_email]" already exists.

Error code 119: The CloudFlare email address "[$cloudflare_email]" has already been registered, but has not been confirmed. Please double check your mail box for the confirmation link.

Error code 120: The CloudFlare email address "[$cloudflare_email]" is already in use. If you have forgotten your CloudFlare password, you may reset it.

Error code 121: The CloudFlare invitation code "[$signup_code]" is not currently valid or has expired.

Error code 122: The CloudFlare username '[$cloudflare_username]' has been taken. Please choose another.

Error code 123: CloudFlare account [$cloudflare_email] does not exist.

Error code 124: Password failed for CloudFlare account "[$cloudflare_email]". Try again or reset your password.

Error code 125: User with user_key [$user_key] does not exist.

Error code 126: Please correct your CloudFlare e-mail address. You entered "[$cloudflare_email]".

Error code 127: A variation of this email address is already taken in our system. Only one variation is allowed. For example, [email protected] and [email protected] are both the same email address.

Error code 200: No zone_name.

Error code 201: Invalid zone_name.

Error code 202: No resolve_to.

Error code 203: Invalid resolve_to.

Error code 204: No subdomains.

Error code 205: Invalid host value '[$subdomain]' found in subdomains. Not all characters are in allowed set.

Error code 206: Invalid host value '[$subdomain]' found in subdomains. Must be less than 120 characters.

Error code 207: CloudFlare is already hosting [$zone_name] for you.

Error code 208: CloudFlare is already hosting "[$zone_name]" under a different account. If you are the new, rightful owner, please contact CloudFlare and reference this message (#208).

Error code 209: CloudFlare is already hosting "[$zone_name]" under a different account. If you are the new, rightful owner, please contact CloudFlare and reference this message (#209).

Error code 210: CloudFlare could not delete [$zone_name]. It was not found in your account.

Error code 211: CloudFlare can not delete [$zone_name]. It has already been banned or removed from your CloudFlare account.

Error code 212: CloudFlare can not delete [$zone_name] from this interface. [$host_provider] is not the authoritative parter with CloudFlare for your domain.

Error code 213: CloudFlare can not delete [$zone_name]. It has already been removed from your CloudFlare account.

Error code 214: CloudFlare is the authorative DNS provider for [$zone_name]. You must login to CloudFlare to deactivate or delete your domain there.

Error code 215: CloudFlare is currently limiting new site signups. Your site [$zone_name] is in the queue. A notification will be sent when your site clears the queue.

Error code 216: Your [$zone_name]'s DNS is hosted by CloudFlare. If you'd like to switch to "[$host_provider]", you must first deactivate and then delete [$zone_name] within CloudFlare. These options are available in the Settings menu.

Error code 217: CloudFlare is not servicing "[$zone_name]" through this [$host_provider]. If you are the rightful owner, you can swap over by deleting any previous CloudFlare domain sign-up and restarting this process. You may also contact CloudFlare and reference this message (#217).

Error code 218: CloudFlare could not detect "[$zone_name]" as a registered domain.

Error code 600: No POST data received.

Error code 601: Connection to CloudFlare DB systems could not be established. Try again in a few minutes. If this problem persists, please contact CloudFlare and reference this message (#601).

Error code 700: Invalid host account [$host_key].

Error code 701: An unknown CloudFlare error has occurred during zone creation and has been logged. We apologize for the inconvenience and we will fix the problem promptly.

Error code 702: An unknown CloudFlare error has occurred during zone authorization and has been logged. We apologize for the inconvenience and we will fix the problem promptly.

Error code 703: An unknown CloudFlare error has occurred during zone deletion and has been logged. We apologize for the inconvenience and we will fix the problem promptly.

Error code 303: Invalid subscription status. Use V, CNL, or ALL.

Error code 311: Invalid User.

Error code 312: Invalid Sub Label.

Error code 313: Sub label will not accept new subscriptions.

Error code 314: Already subscribed and is active.

Error code 315: Already subscribed and the sub cannot be re-activated.

Error code 317: Invalid Zone.

Error code 321: Zone is not active.

Error code 322: Zone is already subscribed to a different sub.

Error code 340: Other Error (Subscribe).

Error code 350: Zone is not active on CloudFlare.

Error code 331: Invalid Subscription Id.

Error code 332: Sub is already canceled.

Error code 333: Other Error (Unsubscribe)

Error code 334: [$zone_name] currently has an active reseller sub. Cancel this subscription before deleting the zone.

4.3 - Error Message Variable Expansions

Certain error messages contain variables, denoted like [$zone_name] or $[host_key]. The different variables are outlined below.