API tokens are intended to be used for automated user not present integrations, that is where requesting interactive authentication would not be possible/desirable.

Users may create API tokens (if they have permissions to do so). The created token may have the same set of permissions and services as the user that created it, or any subset thereof. Users are not permitted to create tokens which have more permissions than themselves.

API tokens do not expire, and are only returned from the API once. After the API token has been created it's permissions may be modified, which allows for granting additional permissions to an application without needing to reconfigure it.

Logging in is intended to be used only when the user is present and actively interacting with the application. Logging in issues a new temporary API token which shares the same permission set as the authenticated user. The token should be discarded when the interactive session ends.

As the token is temporary it has an expiry date which is enforced by the API. The validity time for the token is typically one hour, but may be shorter. If needed the token can be renewed by exchanging it for a new temporary token.

See API Tokens for tokens which are to be used when the user is not present.

The Account Recovery endpoints allows a user to recover access to their account when they have forgotten their authentication credentials.

A CacheFly account is a representation of the entity who will be invoiced for provided services. All other API objects are contained within an account either directly or indirectly.

It is expected that most companies will need only one account. The concept of sub accounts found in the older version 1 API has been directly replaced by the concept of services. Opening multiple accounts is only required to separate invoicing concerns.

Accounts may contain multiple services which can be organised and configured according to your own needs. Each service provides an aggregation point for configuration, logging, statistics, etc.

It is reasonable to think of a service as being similar to the virtual host concept from a typical web server configuration.

When applying changes to a service there may, or may not, be a propagation delay. This is to ensure that a high frequency of changes by a small number of users does not negatively impact the performance of the network as a whole. As such, although we endeavour to make this as fast as possible, and immediate in most cases, the only guarantee is that it will occur eventually.

Service configurationMode enumeration that defines which type of configuration is going to be applied, it can be changed on upon request per service. Following configuration modes are available:

• API_OPTIONS - Simple set of configuration parameters, more details are available in Service Options section.
• API_RULES - Service rules offer more advanced configuration, more details are available in Service Rules section.
• API_RULES_AND_OPTIONS - Use service rules as main configuration set and service options as fallback.
• MANUAL - Custom configuration available upon request.

Note that in failure scenarios we will continue to serve traffic using the last working configuration.

Each service has a set of domains. Depending on available features, one or more defaults will be added to the service when it is created, including <uniqueName>.cachefly.net.

Adding a domain to a service will configure the CacheFly edge servers to route all traffic received for that name through the configuration for that service. Each domain name must be a fully qualified hostname. If you wish to serve traffic for both www.example.com and example.com then you will need to add both names.

Once created domains are automatically related to TLS certificates if there are any that matches the name. You do not need to maintain the relationship between domains and certificates.

Please note that the propagation delay mentioned in the description of a service also applies to service domains.

You should configure the DNS for your custom domains to alias one of the default service domain names that you are given.

A time to live (TTL) of 86400 seconds (24 hours) is recommended to gain a performance advantage from shared DNS caching. Note that setting your TTL lower than 2400 seconds (1 hour) is suboptimal for performance.

DNS Example:

www.example.com.    IN    86400    CNAME    <uniqueName>.cachefly.net

You should never place a CacheFly IP address in your DNS configuration as that prevents us from applying early geographic performance optimisations, and may prevent us from ensuring continued uptime during maintenance or unscheduled outages.

If you are unable to use a CNAME, you should look into using provider specific equivalents (e.g. ANAME, ALIAS, RECORD LINKING, etc).