.png)
Fastly Integration Guide
Integrate Fastly with enterprise systems through authenticated REST APIs, versioned configuration workflows, purge operations, metrics endpoints, and selected logging or event destinations.
Fastly integration options at a glance
Fastly’s primary integration mechanism is its REST API, which exposes services, versions, domains, backends, dictionaries, ACLs, TLS resources, purging, statistics, and logging configuration. Fastly also provides selected bulk operations, certificate-related APIs, product-specific notifications, and real-time log delivery to supported destinations. Authentication uses Fastly API tokens or other Fastly-supported API credentials, typically supplied through the Fastly-Key header. Martini can consume these JSON APIs, schedule metrics synchronization, orchestrate versioned configuration changes, invoke purge operations, receive compatible HTTP payloads, and expose controlled APIs for internal publishing or deployment systems.
| Integration point | Supported by Fastly? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage Services, Versions, Domains, Backends, Dictionaries, ACLs, TLS resources, purges, statistics, and logging configuration. | Martini can consume authenticated Fastly REST endpoints, parse JSON responses, map resources, and expose internal APIs that abstract Fastly operations. |
| Configuration and deployment APIs | Yes | Retrieve or clone a Version, modify service configuration, validate the resulting version, and activate it. | Martini workflows can orchestrate multi-step promotion with approvals, state comparison, validation, concurrency safeguards, and rollback handling. |
| Purge and cache invalidation APIs | Yes | Invalidate cached content by URL, surrogate key, or other supported purge criteria after publication or deployment activity. | Martini can receive a publication request, resolve affected cache keys, invoke purge endpoints, retry transient failures, and persist an audit result. |
| Statistics and metrics APIs | Yes | Retrieve Fastly traffic, performance, and operational statistics for reporting, alerting, capacity analysis, or database storage. | Scheduled Martini workflows can retrieve time ranges, normalize JSON responses, calculate derived indicators, and write results to monitoring systems or databases. |
| Webhooks and outbound callbacks | Limited | Provide notifications for selected Fastly products and operational event types; universal coverage across resources should not be assumed. | Martini can receive compatible HTTP notifications when the specific Fastly product and event support them, or use polling when notifications are unavailable. |
| Bulk and asynchronous operations | Limited | Support selected bulk-style actions, particularly cache purging and other resource-specific operations, rather than one universal bulk API. | Martini can batch supported purge or resource operations while applying bounded concurrency, response tracking, and partial-failure handling. |
| File and certificate APIs | Limited | Manage TLS certificates, certificate-related metadata, and TLS domains through Fastly APIs; no general-purpose file repository was identified. | Martini can securely pass certificate-related metadata or material where permitted, validate responses, and prevent sensitive values from appearing in logs. |
| Database and analytics access | Limited | Access analytics and operational data through metrics APIs, real-time logging destinations, or supported observability integrations rather than a relational database interface. | Martini can poll metrics, consume compatible log payloads, transform data, and write it to a supported database, queue, or monitoring platform. |
| Authentication | Yes | Authenticate API requests using Fastly API tokens or other Fastly-supported credentials, commonly supplied with the Fastly-Key header. | Martini stores credentials in protected environment configuration or secrets and sends them through request authentication settings with least-privilege access. |
How Fastly exposes data and business events
Fastly REST APIs
Fastly’s REST API is the principal management and configuration interface. It covers account resources, Services, Versions, Domains, Backends, Dictionaries, ACLs, TLS resources, purging, statistics, and logging configuration.
Martini implementation pattern
Martini consumes Fastly REST endpoints from a workflow, supplies token-based authentication, parses JSON responses, applies business rules, and maps the result to an internal or downstream model. Martini can also expose a controlled API that hides Fastly-specific operations from publishing, deployment, or operations applications.
Implementation sequence
Versioned configuration APIs
Fastly commonly organizes service configuration around Service Versions. Integrations can retrieve or clone a Version, modify Domains, Backends, Dictionaries, ACLs, or other resources, validate the result, and activate it.
Martini implementation pattern
Martini orchestrates the configuration lifecycle as a multi-step workflow. It compares desired and current state, protects against concurrent changes, validates before activation, records the activated Version, and routes failures for review or rollback.
Implementation sequence
Fastly purge APIs
Fastly supports cache invalidation through API operations including URL and surrogate-key purging. Purge requests can be initiated after content publication, deployment, or controlled operational changes.
Martini implementation pattern
Martini receives a publication or deployment request, resolves affected URLs or surrogate keys, invokes the appropriate Fastly purge endpoint, handles rate limits and transient errors, and returns an auditable status to the source system.
Implementation sequence
Fastly metrics APIs
Fastly exposes statistics and metrics endpoints that can provide traffic, performance, and operational data for reporting, alerting, capacity analysis, or storage.
Martini implementation pattern
A scheduled Martini workflow retrieves the required service and time-range data, normalizes Fastly JSON responses, calculates derived values such as error-rate trends, and writes the results to a database or monitoring platform.
Implementation sequence
Fastly logging destinations
Fastly supports real-time log streaming to external destinations. The exact architecture depends on the selected destination and whether an intermediary storage, queue, or endpoint is used.
Martini implementation pattern
Where Fastly sends compatible HTTP log payloads to Martini or an intermediary, Martini can validate, enrich, transform, and route the data. High-volume designs should consider batching, queues, replay, retention, and deduplication rather than synchronous processing of every event.
Implementation sequence
Common Fastly integration patterns
Pattern 1: Purge Fastly cache after content publication
When to use this pattern
Use this pattern when a content or commerce application publishes changes that must become visible at the edge. The workflow resolves affected URLs or surrogate keys, avoids unnecessary invalidations, and returns a clear operational result to the publishing system.
Integration direction
Example Mapping
| Fastly Field | Canonical Field | Target Field |
|---|---|---|
| publicationId | changeReference | correlation_id |
| affectedUrls | purgeUrls | url |
| surrogateKeys | purgeKeys | surrogate_key |
| publishedAt | eventTime | requested_at |
Martini implementation pattern
Martini receives a publication request or scheduled batch, applies cache-key rules, calls the appropriate Fastly purge endpoint, and stores the response. It uses bounded retries for transient failures, handles rate limiting, and reports partial or failed purges without treating an unconfirmed operation as successful.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- monitoring
Pattern 2: Promote Fastly service configuration
When to use this pattern
Use this pattern to promote controlled changes to Backends, Domains, Dictionaries, ACLs, or related configuration between environments. It is appropriate when activation requires approval, validation, auditability, and protection against concurrent changes.
Integration direction
Example Mapping
| Fastly Field | Canonical Field | Target Field |
|---|---|---|
| serviceId | fastlyServiceId | Service |
| backend.address | originHost | Backend.address |
| dictionaryEntries | edgeConfiguration | Dictionary items |
| desiredVersion | configurationVersion | Version |
Martini implementation pattern
Martini retrieves the current Service and Version, compares desired state, creates or clones a working Version, applies resource changes, validates the configuration, and activates it after approval. The workflow records the activated Version and routes validation, authorization, conflict, and partial-completion failures for recovery or rollback.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- validation
- error handling
Pattern 3: Synchronize Fastly metrics to monitoring
When to use this pattern
Use this pattern when operations teams need Fastly statistics in a database or monitoring platform alongside application and infrastructure telemetry. A scheduled workflow can retrieve bounded time ranges and calculate consistent indicators.
Integration direction
Example Mapping
| Fastly Field | Canonical Field | Target Field |
|---|---|---|
| service_id | edgeServiceId | service |
| start_time | intervalStart | timestamp |
| requests | requestCount | requests |
| errors | errorCount | errors |
Martini implementation pattern
A scheduled Martini workflow calls Fastly metrics endpoints, handles pagination or time windows where applicable, normalizes JSON, calculates error-rate trends, and sends the result to Datadog or a database. Checkpoints, duplicate-window protection, bounded retries, and sanitized logs support reliable repeated execution.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- database or monitoring integration
- checkpointing
- error handling
Pattern 4: Route Fastly edge logs to enterprise observability
When to use this pattern
Use this pattern when Fastly real-time logs must be enriched, retained, or routed to an internal monitoring or storage process. It is most suitable when the selected Fastly destination can deliver compatible HTTP payloads or an intermediary can provide them to Martini.
Integration direction
Example Mapping
| Fastly Field | Canonical Field | Target Field |
|---|---|---|
| timestamp | eventTime | _time |
| status | httpStatus | status |
| url | requestUrl | request.url |
| service_id | edgeServiceId | fastly.service_id |
Martini implementation pattern
Martini receives or retrieves compatible log batches, validates and enriches entries with deployment metadata, transforms them for the target observability platform, and records batch-level processing status. Queueing, deduplication, replay, and failure isolation should be used when log volume exceeds synchronous processing capacity.
Martini capabilities used
- workflow orchestration
- HTTP API consumption
- data mapping
- batch processing
- messaging or queues
- monitoring
Applications commonly integrated with Fastly
Fastly is commonly connected to content, commerce, cloud storage, observability, and deployment workflows. Martini can orchestrate these integrations when business rules, enrichment, auditability, or coordination across multiple systems is required.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Amazon S3 | Store Fastly real-time logs, archived delivery data, or exported operational data for analysis and retention. | Fastly → Amazon S3 | Fastly delivers logs to the configured destination; Martini can process compatible payloads, enrich them with application metadata, and persist or route them to Amazon S3 through an HTTP or storage integration. |
| Google Cloud Storage | Retain edge logs for data processing, reporting, and compliance workflows. | Fastly → Martini → Google Cloud Storage | Martini receives or retrieves compatible Fastly log data, normalizes batches, applies retention rules, and writes the resulting files or payloads to Google Cloud Storage. |
| Datadog | Centralize Fastly performance, traffic, and edge telemetry for monitoring and alerting. | Fastly → Martini → Datadog | A scheduled Martini workflow retrieves selected Fastly metrics, calculates derived indicators such as error-rate trends, and sends normalized data to Datadog or an approved intermediary. |
| Splunk | Search and investigate Fastly security, access, and operational logs for compliance and incident response. | Fastly → Splunk | Fastly streams logs to a supported Splunk destination; Martini can enrich or route compatible HTTP log payloads before indexing where the deployment architecture requires an intermediary. |
| New Relic | Correlate Fastly edge performance with application and infrastructure telemetry. | Fastly → New Relic | Fastly sends supported observability data to New Relic, while Martini can synchronize selected Fastly statistics or operational signals into related monitoring workflows. |
| Amazon CloudWatch | Combine Fastly operational data with AWS monitoring and alerting. | Fastly → Martini → Amazon CloudWatch | Martini retrieves Fastly metrics or processes compatible log data, maps it to the required CloudWatch structure, and invokes the appropriate AWS endpoint or intermediary. |
| Shopify | Purge Fastly-cached storefront content after catalog, pricing, or merchandising changes. | Shopify → Martini → Fastly | Martini receives a Shopify publication event or scheduled change set, resolves affected URLs or surrogate keys, calls Fastly’s purge API, and records the outcome for audit and retry handling. |
| Salesforce | Purge customer-facing or commerce content after publishing changes from Salesforce-based applications. | Salesforce → Martini → Fastly | A Martini API or workflow accepts the Salesforce change notification, applies cache-key business rules, invokes Fastly purge endpoints, and returns a controlled status to the publishing process. |
How to build a Fastly integration in Martini
Objective
Establish authenticated access to Fastly using a token or other Fastly-supported credential with only the permissions required by the workflow.
Instructions in Martini
- Configure the Fastly API base URL and required request headers.
- Store the Fastly API token in protected environment configuration or secrets.
- Separate development, staging, and production credentials where practical.
- Verify access with a read operation before enabling writes.
Objective
Select the trigger that matches the integration’s operating model, such as an API request, publication event, product-specific notification, or scheduled synchronization.
Instructions in Martini
- Use an API or webhook-style trigger when the confirmed Fastly product supports the required event.
- Use a scheduler for metrics retrieval, reconciliation, or polling-based synchronization.
- Use an intermediary queue or storage layer for high-volume log processing when appropriate.
Objective
Call the relevant Fastly REST endpoint and obtain the current resource, configuration version, metrics interval, purge response, or compatible log payload.
Instructions in Martini
- Build requests for the specific Service, Version, resource, or time range.
- Handle pagination and bounded time windows where the endpoint requires them.
- Capture request identifiers, status codes, and correlation data without logging secrets.
Objective
Coordinate the Fastly calls and downstream actions as a maintainable Martini workflow with explicit branches for validation, approval, success, and failure.
Instructions in Martini
- Separate read, transform, write, and audit stages.
- Use conditional routing for configuration validation, permissions, and partial completion.
- Track Version activation, purge results, or metrics checkpoints explicitly.
Objective
Convert Fastly JSON resources, metrics, configuration values, or logs into the canonical and target-specific structures required by downstream systems.
Instructions in Martini
- Map actual Fastly objects such as Services, Versions, Backends, Dictionaries, and ACLs.
- Normalize timestamps, identifiers, status values, and metric intervals.
- Apply environment-specific transformations without embedding credentials or sensitive certificate material.
Objective
Use validation and policy checks to prevent unsafe purges, invalid configuration changes, duplicate processing, or unauthorized production activation.
Instructions in Martini
- Compare desired and current configuration before creating or activating a Version.
- Validate required fields, target environments, cache keys, and operational thresholds.
- Require approval or additional controls for production activation where appropriate.
Common Fastly data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Services | Represent Fastly delivery or edge service configurations and provide the parent context for many configuration resources. | Deployment platforms, configuration repositories, internal service catalogs | Martini retrieves or updates Services through REST workflows, validates identifiers, and records correlation and audit data. |
| Versions | Provide versioned Fastly configuration units that can be modified, validated, activated, or rolled back. | CI/CD platforms, change-management systems, configuration repositories | Martini compares desired and current state, applies controlled changes, validates the Version, tracks activation, and handles conflicts. |
| Domains | Define hostnames assigned to a Fastly Service. | DNS platforms, certificate-management processes, service catalogs | Martini maps domain data, checks service and version relationships, and coordinates domain or TLS-related workflows. |
| Backends | Define origin servers or origin endpoints used by a Fastly Service. | Infrastructure inventories, deployment systems, origin configuration stores | Martini transforms endpoint settings, applies environment-specific rules, and submits changes within a versioned configuration workflow. |
| Dictionaries | Store key-value configuration data associated with a Service version. | Feature configuration systems, application configuration stores, deployment pipelines | Martini synchronizes approved key-value changes, validates required fields, and tracks the target Version and operation result. |
| ACLs | Represent access control lists and their entries for edge request controls. | Security operations platforms, IP or policy management systems | Martini maps approved entries, applies business rules, and handles partial failures and version activation sequencing. |
Authentication and security considerations
Token-based authentication
Fastly’s management API supports API tokens and other Fastly-supported credentials, commonly supplied through the Fastly-Key header. API tokens are generally preferred when independently revocable and more specific permissions are required.
Least-privilege access
Fastly permissions vary by user, service account, token, account, and operation. Use separate credentials for environments and restrict access to the Services, configuration resources, purging, metrics, or administrative functions required by each workflow.
Secret protection
- Store Fastly credentials in protected Martini environment configuration or secrets.
- Do not embed tokens in workflow definitions or write them to logs.
- Sanitize certificate material, configuration values, and API responses before logging.
Operational considerations for Fastly integrations
Rate limits and pagination
Handle HTTP 429 responses, respect response headers when provided, use bounded exponential backoff, and implement endpoint-specific pagination. Avoid repeatedly polling unchanged Services, Domains, or other resources.
Versioning and activation
Configuration workflows should compare desired and current state, account for concurrent Version changes, validate before activation, track the activated Version, and provide a recovery or rollback path.
Idempotency and retries
Use correlation identifiers and operation records so retries do not create unintended configuration changes or duplicate processing. Purge and deployment workflows should distinguish accepted, completed, failed, and partially completed operations.
Schema and volume management
Mappings should tolerate additive API fields while validating required values. Real-time logs may require batching, queues, retention, replay, deduplication, and failure isolation rather than synchronous processing of every event.
Testing and monitoring
Test representative Fastly responses, validation failures, permission errors, rate limiting, and Version conflicts in non-production environments. Monitor workflow status, API response codes, checkpoints, activation results, and sanitized operational logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Scripts can call Fastly endpoints, but enterprise integrations often need approvals, state comparison, resource mapping, downstream updates, audit records, and recovery paths. Martini provides a workflow model for coordinating those steps.
Reuse and maintainability
Martini can expose controlled APIs for publishing or deployment systems and reuse common authentication, transformation, validation, and error-handling logic across purge, configuration, metrics, and logging workflows.
Reliable operations
- Apply retries, rate-limit handling, checkpoints, and idempotency rules consistently.
- Separate environment configuration and protect Fastly credentials.
- Route failures and partial completion for operational review.
- Connect Fastly data to databases, monitoring platforms, queues, and other enterprise endpoints.
Frequently asked questions
Fastly is primarily integrated through its REST API, which supports Services, Versions, Domains, Backends, Dictionaries, ACLs, TLS resources, purging, statistics, and logging configuration. Fastly also supports selected product-specific notifications, bulk operations, and real-time log destinations. Enterprise workflows should use Fastly API tokens or other supported credentials and account for version activation, rate limits, pagination, and retries.
Yes. Martini can integrate with Fastly by consuming its authenticated REST APIs, processing JSON responses, orchestrating purge and versioned configuration workflows, synchronizing metrics, and exposing controlled APIs for internal applications or deployment systems. It can also participate in compatible Fastly logging or product-specific notification flows.
No. A dedicated Fastly connector is not required. Martini can use Fastly’s confirmed native integration mechanisms, including REST APIs, API-token authentication, selected notification or logging endpoints, and scheduled API polling. A native Martini Fastly connector was not verified in the supplied research.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Fastly. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Fastly, cloud infrastructure, monitoring platforms, or other third-party systems based on subscriptions, usage, and deployment model.
The Fastly REST API is the primary and recommended method for management, configuration, purge, metrics, and resource operations. Use versioned configuration APIs for controlled deployment, metrics endpoints for scheduled synchronization, and supported logging destinations for edge-log routing. Product-specific notifications should be used only after confirming coverage for the required event.
Fastly provides notification and event capabilities for selected products and operational scenarios, but universal webhook coverage should not be assumed. No general-purpose Fastly GraphQL API was confirmed, and no Fastly SOAP API was identified. Martini can use REST APIs, polling, or supported logging and event destinations instead.
Martini can retrieve Fastly resources or metrics on demand or on a schedule, map actual objects such as Services, Versions, Backends, Dictionaries, and ACLs to canonical models, and write transformed data to databases, monitoring platforms, or other applications. Workflows can apply pagination, checkpoints, validation, deduplication, and environment-specific business rules.
Martini workflows can distinguish authentication failures, authorization issues, invalid identifiers, validation errors, rate limiting, transient API failures, and concurrent Version conflicts. Bounded exponential backoff, correlation identifiers, idempotent state comparisons, checkpoints, audit records, and explicit rollback or recovery paths help prevent duplicate purges and unsafe configuration activation.
Related Martini documentation
Workflows
Data handling
Integrate Fastly with Martini
Use Martini to build maintainable Fastly integrations for cache purging, configuration promotion, metrics synchronization, and edge-log processing.