Skip to main content

Fastly Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to a Fastly location.
fastly_api.png

Fastly

Create a Fastly Destination​

  1. Click the + icon on the Nexset that will be sent to the Fastly destination, and select the Send to Destination option from the menu.

  2. Select the Fastly connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Fastly account, and click Next; or, create a new Fastly credential for use in this flow.

  3. In Nexla, Fastly destinations can be created using pre-built endpoint templates, which expedite destination setup for common Fastly API write operations. Each template is designed specifically for the corresponding Fastly endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Fastly destinations can also be configured manually, allowing you to send data to Fastly API endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Fastly API endpoints. Each template is designed specifically for the corresponding Fastly write operation, making destination setup easy and efficient.

  • To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

Create a New Service

Creates a new Fastly service. Use this endpoint to provision new CDN services programmatically, for example when onboarding new application environments or automating infrastructure provisioning pipelines.

  • This endpoint requires no additional URL parameter configuration. The request body should contain the service attributes as a JSON object, including at minimum the name and type fields. Nexla will send each record in the Nexset as a separate create request.
  • The type field determines the service type — use vcl for standard VCL-based services or wasm for Fastly Compute services.

After creating a service, it will have no active version and no configuration. You will need to create a version, add backends and domains, and activate the version before the service will serve traffic. For reference, see the Fastly services API documentation.

Update a Service

Updates a Fastly service's name or comment. Use this endpoint to rename services or update their descriptions as part of automated infrastructure management workflows.

  • Enter the alphanumeric string identifying the service to be updated in the Service Id field. Service IDs can be found using the Fastly control panel or by running the List All Services data source endpoint.
  • The request body should contain the fields to be updated as a JSON object. Supported fields include name (the new service name) and comment (an optional description).

This endpoint only updates the service's metadata (name and comment). To change the service's CDN configuration — such as backends, domains, or caching rules — you must create and activate a new service version. For reference, see the Fastly services API documentation.

Delete a Service

Deletes a Fastly service permanently. Use this endpoint for automated decommissioning workflows or cleanup pipelines that remove services no longer in use.

  • Enter the alphanumeric string identifying the service to be deleted in the Service Id field.
Destructive Operation

Deleting a Fastly service is permanent and cannot be undone. All service configuration, versions, and associated settings will be permanently removed. Ensure the correct service ID is provided before activating this destination.

Create a Service Version

Creates a new configuration version for a Fastly service. In Fastly, all configuration changes must be made on a new (unlocked) version, which is then activated to take effect. Use this endpoint when starting a new configuration change cycle.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • The request body may optionally include version metadata as a JSON object. To create a blank new version, the body can be empty.

After creating a new version, you can add backends, domains, ACLs, and other configuration to it using the appropriate Fastly API write endpoints. Once the version is fully configured and validated, use the Activate a Service Version endpoint to push it live. For reference, see the Fastly service versions documentation.

Activate a Service Version

Activates a specific configuration version for a Fastly service, making it the live version serving traffic. This is the final and required step in any Fastly configuration automation workflow — all configuration changes made to a version are staged until activation.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version to activate in the Version Id field. Only non-locked, valid versions can be activated.
Live Traffic Impact

Activating a service version immediately affects live traffic. Fastly performs validation checks before activation, but ensure the version configuration has been thoroughly reviewed and tested before activating it in production.

Once activated, the previous version is automatically locked and can no longer be edited. You can clone a locked version to create a new editable copy using the Clone a Service Version endpoint. For reference, see the Fastly service versions documentation.

Clone a Service Version

Clones an existing Fastly service version to create a new editable working copy with the same configuration. Use this endpoint to duplicate an existing configuration as the starting point for making changes, which is the standard Fastly workflow for updating live configurations.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version to clone in the Version Id field. You can clone any version, including the currently active version.

Cloning a version creates a new unlocked version with all the same configuration as the source version. The cloned version can then be modified and activated. This is the recommended approach when you need to make changes to an already-active service configuration. For reference, see the Fastly service versions documentation.

Purge All Cached Objects for a Service

Purges all cached objects for a specified Fastly service, forcing all subsequent requests to be served fresh from the origin. This is one of the most impactful write operations Fastly provides and is commonly used after deploying new application versions or content updates.

  • Enter the alphanumeric string identifying the service whose cache should be purged in the Service Id field.
  • No request body is required for this operation.
Service-Wide Cache Purge

This operation purges the entire cache for the specified service across all Fastly edge nodes globally. Until the cache is repopulated, all requests will be forwarded to your origin servers — this may temporarily increase origin load. Use targeted purging via surrogate keys for more surgical cache invalidation.

The API token used in your credential must have either the global or purge_all scope to use this endpoint. Tokens with only purge_select scope will receive a 403 error. For reference, see the Fastly purging documentation.

Purge Cached Objects by Surrogate Key

Purges all cached objects associated with a specific surrogate key, enabling targeted cache invalidation without clearing the entire service cache. Surrogate keys (also known as cache tags) are custom identifiers applied to cached responses via the Surrogate-Key response header from your origin.

  • Enter the surrogate key identifying the cached objects to purge in the Surrogate Key field. Surrogate keys are set by your origin server using the Surrogate-Key HTTP response header and can be any string value that logically groups related cache objects.
  • No request body is required for this operation.
  • For example, a CMS might tag all cached objects related to a specific article with surrogate key article-12345. When the article is updated, purging that surrogate key invalidates only those cached objects.

The API token used in your credential must have either the global or purge_select scope to use this endpoint. Surrogate key purging is significantly faster than purge-all for large content libraries and is the recommended approach for production cache invalidation workflows. For reference, see the Fastly purging documentation.

Create a Backend

Creates a new backend (origin server) on a specified service version. Backends define where Fastly forwards requests that cannot be served from cache, including the origin hostname, port, TLS settings, and connection timeouts.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version on which to create the backend in the Version Id field. The version must be unlocked (not yet activated or locked).

  • The request body should contain the backend configuration as a JSON object. Required fields include:

    • name — A unique name for the backend within the service version.
    • address — The hostname or IP address of the origin server.

Backend changes take effect only after the service version is activated. Ensure all backend settings are validated before activating the version. For complete backend configuration options, refer to the Fastly backends documentation.

Update a Backend

Updates the configuration of an existing backend on a service version, including address, port, timeouts, and health check settings. Use this endpoint to modify origin server configurations as part of automated infrastructure management.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • Enter the name of the backend to update in the Backend Name field. This must exactly match the backend's name as configured on the service version.
  • The request body should contain the backend fields to update as a JSON object.

Backend updates require an unlocked service version. If the current active version is locked, you must first clone it using the Clone a Service Version endpoint, make your changes on the cloned version, then activate it. For reference, see the Fastly backends documentation.

Delete a Backend

Removes a backend from a specified service version. Use this endpoint to decommission origin servers or clean up unused backends as part of infrastructure automation workflows.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • Enter the name of the backend to remove in the Backend Name field.

Removing a backend from a service version only affects that specific version. The change takes effect when the version is activated. For reference, see the Fastly backends documentation.

Add a Domain to a Service Version

Adds a domain to a Fastly service version. Use this endpoint to programmatically configure the hostnames that the service should accept and route traffic for.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • The request body should contain the domain details as a JSON object, including at minimum the name field (the domain name to add).

Domain changes take effect only after the service version is activated. For reference, see the Fastly domains documentation.

Update a Domain

Updates a domain associated with a Fastly service version. Use this endpoint to modify domain names or their associated comments as part of configuration management workflows.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • Enter the current domain name to update in the Domain Name field. This must exactly match the existing domain name on the version.
  • The request body should contain the updated domain fields as a JSON object.

Domain updates require an unlocked service version. For reference, see the Fastly domains documentation.

Create an ACL on a Service Version

Creates a new Access Control List (ACL) on a Fastly service version for IP-based access control. ACLs are named containers for IP address rules that can be used in VCL to allow or block traffic based on client IP addresses.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • The request body should contain the ACL definition as a JSON object, including at minimum the name field (a unique name for the ACL within the service version).

Creating an ACL on a service version only creates the named container. After the version is activated, use the Add an IP Entry to an ACL or Bulk Update ACL Entries endpoints to populate the ACL with IP rules. ACL entries can be modified at runtime without creating a new service version. For reference, see the Fastly ACL documentation.

Add an IP Entry to an ACL

Adds an IP address or CIDR range entry to an existing Fastly ACL. Use this endpoint to dynamically update IP allowlists or blocklists without requiring a new service version activation.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the alphanumeric string identifying the ACL in the Acl Id field. ACL IDs can be retrieved using the List Service ACLs data source endpoint.

  • The request body should contain the ACL entry as a JSON object with the following fields:

    • ip — The IP address or CIDR range to add (e.g., 192.168.1.0/24).
    • subnet — The subnet mask as an integer (e.g., 24 for a /24 subnet). Optional if the IP includes CIDR notation.
    • negated — Boolean. Set to true to negate (block) this entry; set to false or omit to allow.
    • comment — An optional description for the entry.

ACL entry changes take effect in real time without requiring a new service version activation. This makes ACLs well-suited for dynamic IP management scenarios such as security incident response. For reference, see the Fastly ACL entries documentation.

Bulk Update ACL Entries

Performs bulk create, update, and delete operations on ACL entries in a single atomic request. Use this endpoint when synchronizing large IP lists or making multiple ACL changes as part of an automated security workflow.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the alphanumeric string identifying the ACL in the Acl Id field.

  • The request body should contain a JSON object with an entries array. Each entry in the array should include:

    • op — The operation to perform: create, update, or delete.
    • ip — The IP address or CIDR range.
    • negated — Boolean indicating whether the entry is negated (blocked).

Bulk ACL updates are atomic — either all operations succeed or none of them are applied. This makes bulk updates safer for large-scale IP list management. For reference, see the Fastly ACL entries documentation.

Create an Edge Dictionary on a Service Version

Creates a new edge dictionary (also called an edge config store) on a Fastly service version. Edge dictionaries are key-value stores attached to a service version that can be referenced in VCL for dynamic routing, feature flags, or configuration lookups.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the integer identifying the service version in the Version Id field. The version must be unlocked.
  • The request body should contain the dictionary definition as a JSON object, including at minimum the name field (a unique name for the dictionary within the service version).

Like ACLs, edge dictionary items can be modified at runtime without activating a new service version. After creating the dictionary and activating the service version, use the Bulk Update Dictionary Items endpoint to populate it with key-value pairs. For reference, see the Fastly dictionaries documentation.

Bulk Update Dictionary Items

Performs bulk create, update, and delete operations on edge dictionary items in a single atomic request. Use this endpoint to synchronize key-value data into a Fastly edge dictionary from an external data source, enabling dynamic configuration management at the edge.

  • Enter the alphanumeric string identifying the service in the Service Id field.
  • Enter the alphanumeric string identifying the dictionary in the Dictionary Id field. Dictionary IDs can be retrieved using the List Service Dictionaries data source endpoint.

  • The request body should contain a JSON object with an items array. Each item in the array should include:

    • op — The operation to perform: create, update, upsert, or delete.
    • item_key — The dictionary key (a string of up to 256 characters).
    • item_value — The dictionary value (a string of up to 8,000 characters).

Bulk dictionary updates take effect in real time without requiring a new service version activation. This makes edge dictionaries well-suited for scenarios like feature flags, routing tables, or configuration data that needs to change frequently without a full deployment. For reference, see the Fastly dictionary items documentation.

Create a KV Store

Creates a new KV store — Fastly's global, versionless key-value storage used by Fastly Compute services. KV stores are shared across Compute services and automatically replicate to all Fastly edge nodes globally.

  • This endpoint requires no URL path parameters. The request body should contain the KV store configuration as a JSON object, including at minimum the name field (a unique name for the store).

KV stores are distinct from edge dictionaries. KV stores are versionless containers used with Fastly Compute (WebAssembly), while edge dictionaries are tied to VCL service versions. For reference, see the Fastly KV store documentation.

Insert or Update a KV Store Item

Inserts or updates a key-value pair in a Fastly KV store. Use this endpoint to write data into a KV store from a Nexla pipeline, enabling real-time synchronization of data from any Nexla source to your Fastly edge applications.

  • Enter the identifier of the KV store in the Store Id field. KV store IDs can be retrieved using the List All KV Stores data source endpoint.
  • Enter the key for the item in the Key field. Keys can be any string value that identifies the item within the store.
  • The request body should contain the value to store. The value is passed as a raw string or binary payload.

KV store writes are globally replicated and take effect at the edge within seconds. This endpoint uses a PUT method, meaning it will create the key if it does not exist and overwrite it if it does. For reference, see the Fastly KV store items documentation.

Configure Manually​

Fastly destinations can be manually configured to send data to any valid Fastly API endpoint.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Fastly API after each call to a new Nexla webhook data source.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Fastly API from the Method pulldown menu. Common Fastly API methods include:

    • POST: For creating new resources (services, versions, backends, domains, ACLs, KV stores).
    • PUT: For replacing or activating resources (activating a service version, writing a KV store item).
    • PATCH: For partial updates (bulk ACL entries, bulk dictionary items).
    • DELETE: For removing resources (deleting a service, backend, or domain).

Data Format​

  1. Select the format in which the Nexset data will be sent to the Fastly API from the Content Format pulldown menu. Fastly API endpoints expect JSON format for most write operations. Nexla will automatically convert the data to the selected format for each API call.

API Endpoint URL​

  1. Enter the URL of the Fastly API endpoint to which you want to send the Nexset data in the URL field. Fastly API endpoints use the base URL https://api.fastly.com/ followed by the resource path.

    For example:

    • https://api.fastly.com/service — create a new service (POST)
    • https://api.fastly.com/service/{'{service_id}'}/purge_all — purge all cached objects for a service (POST)
    • https://api.fastly.com/purge/{'{surrogate_key}'} — purge by surrogate key (POST)

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2).

    You do not need to include the Fastly-Key authentication header here — it is automatically added to all requests by Nexla using the value from your Fastly credential.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Fastly destination, select the attributes from the Exclude Attributes pulldown menu.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Record batching is particularly useful for Fastly endpoints that support bulk operations, such as Bulk Update ACL Entries or Bulk Update Dictionary Items. These endpoints accept arrays of operations in a single request, making batching an efficient way to synchronize large datasets.

Response Webhook​

Optional

Nexla can automatically send the response received from the Fastly API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and any additional information returned after each call.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Fastly API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.
  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Fastly API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Fastly API using the current settings.

Save & Activate the Destination​

  • Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to the configured Fastly endpoint, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to the Fastly API until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.