Fastly is a cloud edge computing and content delivery network (CDN) platform that accelerates websites, apps, and APIs by caching content close to end users. Beyond delivery, it provides security services — DDoS protection, WAF, and TLS termination — plus edge computing with WebAssembly, KV stores, and programmable caching via VCL. It serves media, e-commerce, and SaaS providers needing low-latency global delivery.
Power end-to-end data operations for your Fastly API with Nexla. Our bi-directional Fastly connector is purpose-built for Fastly, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Fastly or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Fastly workflows fast, secure, and fully governed.
Features
Type: API
SourceDestination
Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
Request optimization with intelligent batching, retry, and caching to minimize API calls and costs
To connect Nexla to Fastly, you need a Fastly API token with appropriate scopes. Fastly uses token-based authentication for all API requests — tokens are passed in the Fastly-Key HTTP header with each request.
Click your username in the upper right corner, then select Account from the dropdown menu.
In the left navigation, click API tokens, then select Personal tokens.
Click the Create token button.
When prompted, re-enter your password to confirm your identity.
In the Name field, enter a descriptive name that identifies the token's purpose (for example, Nexla Integration).
Under Scope, select the appropriate access level for the integration:
global — Full read/write access to all account resources (default). Required for Nexla flows that both read and write data.
global:read — Read-only access to account information, configuration, and statistics. Suitable for Nexla data source flows only.
purge_all — Allows purging all cached objects for a service. Required for purge destination flows.
purge_select — Allows purging by URL or surrogate key. Required for targeted cache invalidation flows.
Optionally, under Service access, restrict the token to specific services. If left unrestricted, the token will have access to all services in your account.
Optionally, set a token expiration date under Expiry to enforce credential rotation policies.
Click Create Token.
Important
After the token is created, it will be displayed only once. Copy the token string immediately and store it in a secure location such as a password manager or secrets vault. You will not be able to view the token value again.
For complete information about Fastly API token types, scopes, and best practices, refer to the Fastly API token documentation.
Automation tokens are recommended for production integrations because they are not tied to a specific user account and remain valid even if a team member leaves.
After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Enter your Fastly API token in the API Key Value field. This is the token string you copied when creating the token in the Fastly control panel. The token is passed as the Fastly-Key HTTP header with every API request Nexla makes to Fastly on your behalf.
Ensure that the API token has the scopes required for the operations you intend to perform. Read-only flows (data sources) require at minimum the global:read scope, while write operations (destinations, purging) require the global or operation-specific scopes such as purge_all or purge_select.
Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.
To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Fastly connector tile, 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.
Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Fastly API endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below.
Get Current User
Returns information about the authenticated user associated with the API token being used. This endpoint is useful for verifying your credentials and confirming which Fastly account is connected to Nexla.
This endpoint requires no additional configuration. Select it from the Endpoint pulldown menu and Nexla will automatically call GET /current_user on the Fastly API using the selected credential.
The response includes user details such as name, email, login, role, and account information.
This endpoint is particularly useful for validating that your Fastly credential is correctly configured and that the API token has the necessary access rights. For additional details, refer to the Fastly current user documentation.
List All Services
Returns a paginated list of all Fastly services associated with the authenticated account. A Fastly service represents a CDN configuration that maps domains to origin servers and defines caching, routing, and security behavior.
This endpoint requires no additional configuration. Select it from the Endpoint pulldown menu to retrieve all services for the connected Fastly account.
Results are paginated automatically by Nexla — all pages of results will be retrieved and combined into a single Nexset.
Each service record includes the service ID, name, type, active version number, creation date, and last updated date.
The service ID returned by this endpoint is required for several other Fastly endpoints. Run this endpoint first to obtain the service IDs for services you wish to inspect in more detail. For reference, see the Fastly services API documentation.
Get Service Details
Returns detailed configuration information about a specific Fastly service, including all versions, active configuration, and metadata. Use this endpoint to inspect or audit a particular service's full configuration.
Enter the unique identifier of the Fastly service in the Service ID field. This alphanumeric string identifies which service's details should be retrieved. Service IDs can be found by:
Running the List All Services endpoint to get a list of all services and their corresponding IDs.
Viewing the Fastly control panel at All services and inspecting the URL, which contains the service ID.
Service details include all versions of the service configuration. The active_version field in the response indicates which version is currently serving traffic. For reference, see the Fastly services API documentation.
List Service Versions
Returns a list of all configuration versions for a specific Fastly service. In Fastly, configuration changes are staged as new versions before being activated. This endpoint is useful for auditing configuration history and tracking changes over time.
Enter the unique identifier of the Fastly service in the Service ID field. You can find this value using the List All Services endpoint or the Fastly control panel.
Each version record includes the version number, whether it is active, whether it is locked, creation date, and last updated date.
Only the active version is serving traffic at any given time. Versions that are "locked" have been activated previously and can no longer be edited — they can only be cloned to create a new editable version. For reference, see the Fastly service versions documentation.
List Service Dictionaries
Returns a list of all edge dictionaries (also called edge config stores) configured for a specific service version. Fastly edge dictionaries are key-value stores attached to a service version that can be used in VCL to drive dynamic routing and configuration decisions.
Enter the unique identifier of the Fastly service in the Service ID field.
Enter the version number of the service configuration in the Version ID field. To get the current active version number, first use the List Service Versions endpoint or the Get Service Details endpoint, and look for the version with active: true.
Results are paginated automatically by Nexla.
Edge dictionaries differ from KV stores in that they are versioned and tied to a specific service version. Modifying dictionary contents does not require creating a new service version. For reference, see the Fastly dictionaries documentation.
List Service Backends
Returns a list of all backends (origin servers) configured for a specific service version. Backends define where Fastly should forward requests that cannot be served from cache, including the hostname, port, SSL settings, and health check configuration.
Enter the unique identifier of the Fastly service in the Service ID field.
Enter the version number of the service configuration in the Version ID field. Use the List Service Versions or Get Service Details endpoint to find the active version number.
Each backend record includes the backend name, address, port, SSL settings, connection timeout, and health check configuration.
Backend configuration changes require creating a new service version and activating it before taking effect. For reference, see the Fastly backends documentation.
List Service Domains
Returns a list of all domains configured for a specific service version. Domains define the hostnames that Fastly accepts requests for and routes to the configured backends.
Enter the unique identifier of the Fastly service in the Service ID field.
Enter the version number of the service configuration in the Version ID field. Use the List Service Versions or Get Service Details endpoint to find the active version number.
Each domain record includes the domain name, any associated comment, and the creation and update timestamps.
Domain configuration is version-specific. After adding or updating domains, you must activate the new service version for the changes to take effect. For reference, see the Fastly domains documentation.
List Service ACLs
Returns a list of all Access Control Lists (ACLs) configured for a specific service version. Fastly ACLs are named lists of IP addresses and CIDR ranges used in VCL to allow or deny traffic based on client IP address.
Enter the unique identifier of the Fastly service in the Service ID field.
Enter the version number of the service configuration in the Version ID field. Use the List Service Versions or Get Service Details endpoint to find the active version number.
Each ACL record includes the ACL name, ID, and the service version it belongs to.
ACL entries (the individual IP rules within an ACL) can be modified at runtime without requiring a new service version activation. However, the ACL itself must be created on a service version and that version must be activated before the ACL can be used. For reference, see the Fastly ACL documentation.
List All Invoices
Returns a list of all billing invoices for the authenticated Fastly account. Use this endpoint to ingest billing and usage data for financial reporting, cost analysis, or automated invoice processing pipelines.
This endpoint requires no additional configuration. Select it from the Endpoint pulldown menu to retrieve all invoices for the connected Fastly account.
Each invoice record includes the invoice period, total charges, and line items broken down by service and region.
Access to billing data requires that the API token used in the credential has sufficient account-level permissions. For reference, see the Fastly invoices documentation.
List All KV Stores
Returns a paginated list of all KV stores associated with the authenticated Fastly account. Fastly KV stores are global key-value storage containers used by Fastly Compute services to store and retrieve persistent data at the edge.
This endpoint requires no additional configuration. Select it from the Endpoint pulldown menu to retrieve all KV stores for the connected Fastly account.
Results are paginated using cursor-based pagination, which Nexla handles automatically.
Each KV store record includes the store ID, name, and creation timestamp. The store ID is required to perform operations on items within the store.
KV stores are distinct from edge dictionaries — KV stores are versionless global containers used with Fastly Compute, while edge dictionaries are versioned and tied to a specific service version. For reference, see the Fastly KV store documentation.
Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.
Fastly data sources can also be manually configured to ingest data from any valid Fastly API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.
Fastly API endpoints use the base URL https://api.fastly.com/ followed by the resource path—for example, https://api.fastly.com/service to list all services, https://api.fastly.com/current_user for the current user, or https://api.fastly.com/billing/v3/invoices for invoices. The only supported method for data sources is GET.
For endpoints that wrap results in a data array, such as {"data": [...], "meta": {...}}, enter $.data[*] as the path to data; for endpoints that return a top-level array directly (such as service versions), enter $[*]. Fastly's paginated list responses include a meta object with pagination context that can be preserved by entering $.meta as the path to metadata. The Fastly-Key authentication header is added automatically and does not need to be added as a request header.
Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Fastly data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.
Click the + icon on the Nexset that will be sent to the Fastly destination, and select the Send to Destination option from the menu. 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.
Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Fastly API endpoints. 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.
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.
Fastly destinations can also be manually configured to send data to any valid Fastly API endpoint. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.
Fastly API endpoints use the base URL https://api.fastly.com/ followed by the resource path—for example, https://api.fastly.com/service to create a new service (POST), https://api.fastly.com/service/{'{service_id}'}/purge_all to purge all cached objects for a service (POST), or https://api.fastly.com/purge/{'{surrogate_key}'} to purge by surrogate key (POST). Common write methods are POST (create), PUT (replace/activate), PATCH (bulk updates), and DELETE (remove). Most operations expect JSON format, and the Fastly-Key authentication header is added automatically and does not need to be added as a request header.
Record batching is particularly useful for Fastly endpoints that support bulk operations, such as Bulk Update ACL Entries or Bulk Update Dictionary Items, which accept arrays of operations in a single request. Enabling the response webhook option lets you capture the response from each API call, such as newly created service, version, or resource IDs.
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 send the data to the configured Fastly endpoint, open the destination resource menu, and select Activate.
The Nexset data will not be sent to the Fastly endpoint until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.
