API v4 Migration

Migration overview

Azion is rolling out API v4 in the coming months to improve platform performance, flexibility, and resource management. This update is more than an API change, it introduces a new core concept, Workloads and new products like Connectors and Custom Pages, and brings significant enhancements to both the API and Azion Console.

API v4 features a new asynchronous, event-driven architecture designed for higher performance and resilience. The new Workload resource model centralizes configuration, making it easier to manage, reuse, and scale your applications. Connectors enables more flexible and secure backend integrations.

Azion API v4 is available in Preview for new developer plan accounts and will be released in waves for General Availability (GA) according to your service plan.

Key points about the migration:

The migration affects both the platform (with the introduction of Workloads, Connectors and Custom Pages) and the API endpoints.
Some configuration settings have moved to new locations to improve reusability and clarity.
New accounts will use API v4 by default. Existing accounts will be migrated in waves.
During the transition, you may see documentation with banners allowing you to switch between v3 and v4 versions of resource.
After your account is migrated you will not be able to use the the v3 API endpoints or create new Domains, Origins or Error Responses. You must use the equivalent new resources.

API v4 represents a technological shift, providing a foundation for future features and improved operational efficiency across the Azion Web Platform.

The changes described in this document will be applied to your account only after your account has been migrated.

API migration

All API endpoints will be migrated to v4 in waves. To view the available endpoints and parameters, see the API v4 reference.

API v3 is now deprecated and will no longer receive updates. It will be discontinued on a future date. After this date, all operations must be performed exclusively using API v4.

Required action

Automations, scripts, and CI/CD pipelines connected to Azion must be updated to use API v4 by the specified deadline.

New Features

JWT authentication.
Activity History via GraphQL for full auditability.
New event-driven architecture.

Migration Benefits

Improved performance
Increased flexibility
Access to future updates
Query parameters: You can now use query parameters to customize API requests. Supported options include ordering results by a specific field, and filtering results by a search term or by field value. This allows you to retrieve and organize data according to your requirements.

Changes in Applications

The functionality of Applications remains unchanged. However, some configuration options that were previously managed within Applications have been moved to other components as part of the migration.

Setting	New Location
Applications > Main Settings > Delivery Settings	Workloads
Applications > Origin Settings	Connectors
Applications > Error Responses	Custom Pages
Applications > Load Balancer	Connectors

Billing and Metrics Changes

When migrating to API v4, there are important changes in how usage is metered and billed. These changes may affect your billing depending on your usage patterns.

Workloads

With the introduction of Workloads, the Requests and Data Transfer metrics are now metered at the Workload level instead of the Application level.

Metric	API v3 (Applications)	API v4 (Workloads)
Requests	Metered per Application	Metered per Workload
Data Transfer	Metered per Application	Metered per Workload

After migration, you will see Requests and Data Transfer metrics in your Workload’s dashboard and billing reports. The measured values remain the same as before migration.

Connectors and Load Balancer

The Data Transfer metric for Load Balancer has changed significantly:

Metric	API v3	API v4
Load Balancer Data Transfer	All traffic through the Application	Only traffic between Connector and Origin

API v3: Data Transfer was calculated based on all traffic flowing through your Application.
API v4: Data Transfer is calculated only on the traffic between your Connector and your origin servers (edge-to-origin traffic).

This change may result in cost optimization, as only the backend traffic is now metered for Load Balancer purposes.

Firewall

The Firewall request metering model has been updated:

Metric	API v3	API v4
Firewall Requests	Only firewalls with Network Shield enabled	All firewalls (all requests passing through)

API v3: Firewall requests were metered only for firewalls with Network Shield enabled.
API v4: Firewall meters all requests that pass through it, including:
- Requests processed by WAF
- Requests processed by Network Shield
- All requests transiting through Firewall

This consolidated approach means you may see an increase in Firewall request counts after migration, as all requests passing through any Firewall are now metered, not just those with Network Shield enabled.

Origin Shield

With the introduction of Connectors in API v4, a new billing metric applies:

Metric	API v3	API v4
Shielded Connectors	Not available	Number of Connectors with Origin Shield enabled

API v3: Origin Shield was available as a separate Add-On with a Subscription. No Shielded Connectors were metered.
API v4: Connectors with Origin Shield enabled are counted as Shielded Connectors and appear in your billing reports.

This is a new metric. If you enable Origin Shield on your Connectors, you will see Shielded Connectors in your billing reports after migration.

API Endpoint Comparison

This section provides a detailed analytical comparison between API v3 and API v4 endpoints, including base URLs, request/response structures, and behavioral differences.

Architecture Overview

Aspect	API v3	API v4
Base URL	`https://api.azionapi.net/`	`https://api.azion.com/v4/`
Architecture	Synchronous	Asynchronous (event-driven)
Authentication	Token in header	Token or JWT in header
Response Format	Direct results in `results` object	State-based with `state` and `data` objects
Resource Model	Nested resources under Applications	Independent resources linked via Deployments
API Version Header	`Accept: application/json; version=3`	Not required

Resource Mapping

API v3 Resource	API v3 Endpoint	API v4 Resource	API v4 Endpoint
Domains	`/domains`	Workloads	`/workspace/workloads`
Origins	`/edge_applications/{id}/origins`	Connectors	`/edge_connector/connectors`
Error Responses	`/edge_applications/{id}/error_responses`	Custom Pages	`/workspace/custom_pages`
Applications	`/edge_applications`	Applications	`/edge_application/applications`
Rules Engine	`/edge_applications/{id}/rules_engine`	Rules Engine	`/edge_application/applications/{id}/rules_engine`
Cache Settings	`/edge_applications/{id}/cache_settings`	Cache Settings	`/edge_application/applications/{id}/cache_settings`
Device Groups	`/edge_applications/{id}/device_groups`	Device Groups	`/edge_application/applications/{id}/device_groups`
Functions	`/edge_functions/functions`	Functions	`/edge_functions/functions`
Digital Certificates	`/digital_certificates`	Digital Certificates	`/digital_certificates/certificates`
Edge Firewall	`/edge_firewall`	Edge Firewall	`/edge_firewall/firewalls`
Network Lists	`/network_lists`	Network Lists	`/workspace/network_lists`

Domains (v3) → Workloads + Deployments (v4)

In API v3, Domains were a single resource that connected an Application to user traffic. In API v4, this concept is split into Workloads (infrastructure and protocol configuration) and Deployments (binding to Applications and other components).

Endpoint Comparison

Operation	API v3	API v4
List all	`GET /domains`	`GET /workspace/workloads`
Get one	`GET /domains/{domain_id}`	`GET /workspace/workloads/{workload_id}`
Create	`POST /domains`	`POST /workspace/workloads`
Update	`PATCH /domains/{domain_id}`	`PATCH /workspace/workloads/{workload_id}`
Delete	`DELETE /domains/{domain_id}`	`DELETE /workspace/workloads/{workload_id}`
Bind to Application	Embedded in Domain creation	`POST /workspace/workloads/{workload_id}/deployments`

Request payload to create a workload

API v3 (Domains):

JSON

01{

02 "name": "string",

03 "cname_access_only": false,

04 "cnames": ["custom.example.com"],

05 "digital_certificate_id": null,

06 "edge_application_id": 1234,

07 "edge_firewall_id": null,

08 "is_active": true,

09 "environment": "production"

10}

API v4 (Workloads):

JSON

01{

02 "name": "string",

03 "active": true,

04 "infrastructure": 1,

05 "protocols": {

06 "http": {

07 "versions": ["http1", "http2"]

08 }

09 },

10 "tls": {

11 "certificate": null,

12 "ciphers": 7,

13 "minimum_version": "tls_1_3"

14 },

15 "domains": ["custom.example.com"],

16 "workload_domain_allow_access": true

17}

Request payload to bind to an application

API v3: Binding occurs automatically during Domain creation via the edge_application_id field.

API v4 (Deployments): A separate request is required:

JSON

01{

02 "name": "string",

03 "active": true,

04 "current": true,

05 "strategy": {

06 "type": "default",

07 "attributes": {

08 "edge_application": 1234,

09 "edge_firewall": null,

10 "custom_page": null

11 }

12 }

13}

Response Structure

API v3 Response (Synchronous):

JSON

01{

02 "results": {

03 "id": 5678,

04 "name": "string",

05 "cnames": ["custom.example.com"],

06 "cname_access_only": false,

07 "digital_certificate_id": null,

08 "edge_application_id": 1234,

09 "is_active": true,

10 "domain_name": "xxxxxxxxxx.map.azionedge.net",

11 "environment": "production"

12 }

13}

API v4 Response (Asynchronous):

JSON

01{

02 "state": "pending",

03 "data": {

04 "id": 5678,

05 "name": "string",

06 "active": true,

07 "infrastructure": 1,

08 "last_editor": "user@example.com",

09 "last_modified": "2025-01-15T10:30:00Z",

10 "domains": ["custom.example.com"],

11 "workload_domain": "xxxxxxxxxx.map.azionedge.net",

12 "workload_domain_allow_access": true,

13 "tls": { "certificate": null, "ciphers": 7, "minimum_version": "tls_1_3" },

14 "protocols": { "http": { "versions": ["http1", "http2"] } }

15 }

16}

Key Behavioral Differences

Aspect	API v3	API v4
Creation flow	Single request creates Domain and binds to Application	Two-step: Create Workload, then create Deployment
Identifier	Numeric `id`	Numeric `id` (Workload) + separate Deployment ID
CNAME Access	`cname_access_only` boolean	`workload_domain_allow_access` boolean
Environment	`environment: "production"` or `"staging"`	`infrastructure: 1` (Production) or `2` (Staging)
Response	Immediate, synchronous	Asynchronous with `state: "pending"`
mTLS	Fields on Domain	Separate `mtls` object with verification, certificate, crl

Origins (v3) → Connectors (v4)

In API v3, Origins were nested resources under Applications. In API v4, Connectors are independent, top-level resources that can be reused across multiple Applications.

Endpoint Comparison

Operation	API v3	API v4
List all	`GET /edge_applications/{app_id}/origins`	`GET /edge_connector/connectors`
Get one	`GET /edge_applications/{app_id}/origins/{origin_key}`	`GET /edge_connector/connectors/{connector_id}`
Create	`POST /edge_applications/{app_id}/origins`	`POST /edge_connector/connectors`
Update	`PATCH /edge_applications/{app_id}/origins/{origin_key}`	`PATCH /edge_connector/connectors/{connector_id}`
Delete	`DELETE /edge_applications/{app_id}/origins/{origin_key}`	`DELETE /edge_connector/connectors/{connector_id}`

Request payload to create a connector

API v3 (Origins - Single Origin):

JSON

01{

02 "name": "My Origin",

03 "origin_type": "single_origin",

04 "addresses": [

05 { "address": "origin.example.com" }

06 ],

07 "origin_protocol_policy": "https",

08 "host_header": "www.example.com",

09 "origin_path": "/api",

10 "connection_timeout": 60,

11 "timeout_between_bytes": 120,

12 "hmac_authentication": false,

13 "hmac_region_name": "",

14 "hmac_access_key": "",

15 "hmac_secret_key": ""

16}

API v3 (Origins - Load Balancer):

JSON

01{

02 "name": "My Load Balanced Origin",

03 "origin_type": "load_balancer",

04 "addresses": [

05 { "address": "origin1.example.com", "weight": 1, "server_role": "primary" },

06 { "address": "origin2.example.com", "weight": 1, "server_role": "primary" }

07 ],

08 "origin_protocol_policy": "https",

09 "host_header": "www.example.com"

10}

API v4 (Connectors - HTTP Type):

JSON

01{

02 "name": "My Connector",

03 "active": true,

04 "type": "http",

05 "attributes": {

06 "addresses": [

07 {

08 "active": true,

09 "address": "origin.example.com",

10 "http_port": 80,

11 "https_port": 443

12 }

13 ],

14 "connection_options": {

15 "dns_resolution": "preserve",

16 "transport_policy": "force_https",

17 "http_version_policy": "http1_1",

18 "host": "www.example.com",

19 "path_prefix": "/api",

20 "following_redirect": false,

21 "real_ip_header": "X-Real-IP",

22 "real_port_header": "X-Real-PORT"

23 },

24 "modules": {

25 "load_balancer": {

26 "enabled": false,

27 "config": {

28 "method": "round_robin",

29 "max_retries": 0,

30 "connection_timeout": 60,

31 "read_write_timeout": 120

32 }

33 },

34 "origin_shield": {

35 "enabled": false,

36 "config": null

37 }

38 }

39 }

40}

API v4 (Connectors - Object Storage Type):

JSON

01{

02 "name": "My Storage Connector",

03 "active": true,

04 "type": "edge_storage",

05 "attributes": {

06 "bucket": "my-bucket",

07 "prefix": "/"

08 }

09}

Response Structure

API v3 Response:

JSON

01{

02 "results": {

03 "origin_id": 123,

04 "origin_key": "abc123def456",

05 "name": "My Origin",

06 "origin_type": "single_origin",

07 "addresses": [

08 { "address": "origin.example.com", "weight": null, "server_role": "primary", "is_active": true }

09 ],

10 "origin_protocol_policy": "https",

11 "host_header": "www.example.com",

12 "origin_path": "/api",

13 "connection_timeout": 60,

14 "timeout_between_bytes": 120

15 }

16}

API v4 Response:

JSON

01{

02 "state": "pending",

03 "data": {

04 "id": 789,

05 "name": "My Connector",

06 "active": true,

07 "type": "http",

08 "last_editor": "user@example.com",

09 "last_modified": "2025-01-15T10:30:00Z",

10 "attributes": {

11 "addresses": [

12 { "active": true, "address": "origin.example.com", "http_port": 80, "https_port": 443 }

13 ],

14 "connection_options": {

15 "dns_resolution": "preserve",

16 "transport_policy": "force_https",

17 "host": "www.example.com",

18 "path_prefix": "/api"

19 },

20 "modules": { "load_balancer": { "enabled": false }, "origin_shield": { "enabled": false } }

21 }

22 }

23}

Key Behavioral Differences

Aspect	API v3	API v4
Resource scope	Nested under Application	Independent top-level resource
Reusability	One Origin per Application	One Connector can serve multiple Applications
Type distinction	`origin_type: "single_origin"` or `"load_balancer"`	`type: "http"` with `load_balancer` enabled for multiple addresses
Protocol policy	`origin_protocol_policy`	`connection_options.transport_policy`
Host header	`host_header`	`connection_options.host`
Path	`origin_path`	`connection_options.path_prefix`
Timeouts	`connection_timeout`, `timeout_between_bytes`	`modules.load_balancer.config.connection_timeout`, `read_write_timeout`
HMAC Auth	Direct fields on Origin	Requires `origin_shield` enabled
Ports	Not configurable	`http_port`, `https_port` per address
Identifier	`origin_key` used for updates	`id` used for all operations

Activate a connector in an application

API v3 - Rules Engine:

JSON

01{

02 "name": "Set Origin Rule",

03 "behaviors": [

04 { "name": "set_origin", "target": "<origin_id>" }

05 ],

06 "criteria": [

07 [{ "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/api" }]

08 ]

09}

API v4 - Rules Engine:

JSON

01{

02 "name": "Set Connector Rule",

03 "active": true,

04 "criteria": [

05 { "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/api" }

06 ],

07 "behaviors": [

08 { "type": "set_edge_connector", "attributes": { "value": "<connector_id>" } }

09 ]

10}

Error Responses (v3) → Custom Pages (v4)

In API v3, Error Responses were nested under Applications. In API v4, Custom Pages are independent resources linked to Workloads via Deployments.

Endpoint Comparison

Operation	API v3	API v4
List all	`GET /edge_applications/{app_id}/error_responses`	`GET /workspace/custom_pages`
Get one	`GET /edge_applications/{app_id}/error_responses/{error_id}`	`GET /workspace/custom_pages/{page_id}`
Create	`POST /edge_applications/{app_id}/error_responses`	`POST /workspace/custom_pages`
Update	`PATCH /edge_applications/{app_id}/error_responses/{error_id}`	`PATCH /workspace/custom_pages/{page_id}`
Delete	`DELETE /edge_applications/{app_id}/error_responses/{error_id}`	`DELETE /workspace/custom_pages/{page_id}`
Bind to Application	Nested under Application	Via Workload Deployment

Request Payload

API v3 (Error Responses):

JSON

01{

02 "name": "My Error Pages",

03 "errors": [

04 {

05 "code": 404,

06 "uri": "/errors/404.html",

07 "ttl": 300,

08 "custom_status_code": 404,

09 "origin_id": 123

10 },

11 {

12 "code": 500,

13 "uri": "/errors/500.html",

14 "ttl": 60,

15 "custom_status_code": 500,

16 "origin_id": 123

17 }

18 ]

19}

API v4 (Custom Pages):

JSON

01{

02 "name": "My Error Pages",

03 "active": true,

04 "pages": [

05 {

06 "code": "404",

07 "page": {

08 "type": "page_connector",

09 "attributes": {

10 "connector": 456,

11 "ttl": 300,

12 "uri": "/errors/404.html",

13 "custom_status_code": 404

14 }

15 }

16 },

17 {

18 "code": "500",

19 "page": {

20 "type": "page_connector",

21 "attributes": {

22 "connector": 789,

23 "ttl": 60,

24 "uri": "/errors/500.html",

25 "custom_status_code": 500

26 }

27 }

28 }

29 ]

30}

Response Structure

API v3 Response:

JSON

01{

02 "results": {

03 "id": 100,

04 "name": "My Error Pages",

05 "errors": [

06 { "code": 404, "uri": "/errors/404.html", "ttl": 300, "origin_id": 123 }

07 ]

08 }

09}

API v4 Response:

JSON

01{

02 "state": "pending",

03 "data": {

04 "id": 200,

05 "name": "My Error Pages",

06 "active": true,

07 "last_editor": "user@example.com",

08 "last_modified": "2025-01-15T10:30:00Z",

09 "pages": [

10 {

11 "code": "404",

12 "page": {

13 "type": "page_connector",

14 "attributes": { "connector": 456, "ttl": 300, "uri": "/errors/404.html" }

15 }

16 }

17 ]

18 }

19}

Key Behavioral Differences

Aspect	API v3	API v4
Resource scope	Nested under Application	Independent top-level resource
Origin per error code	Single `origin_id` for all errors	Different `connector` ID per page code
Binding	Automatic (nested)	Via Workload Deployment with `custom_page` attribute
Code field	`code` (integer)	`code` (string)
Page definition	Flat structure in `errors` array	Nested `page` object with `type` and `attributes`

Rules Engine Comparison

The Rules Engine structure has significant changes in payload format and behavior naming.

Endpoint Comparison

Operation	API v3	API v4
List request rules	`GET /edge_applications/{id}/rules_engine/request/rules`	`GET /edge_application/applications/{id}/request_rules`
List response rules	`GET /edge_applications/{id}/rules_engine/response/rules`	`GET /edge_application/applications/{id}/response_rules`
Get one	`GET .../rules_engine/{phase}/rules/{rule_id}`	`GET .../{phase}_rules/{rule_id}`
Create	`POST .../rules_engine/{phase}/rules`	`POST .../{phase}_rules`
Update	`PATCH .../rules_engine/{phase}/rules/{rule_id}`	`PATCH .../{phase}_rules/{rule_id}`
Delete	`DELETE .../rules_engine/{phase}/rules/{rule_id}`	`DELETE .../{phase}_rules/{rule_id}`

Request Payload Comparison

API v3 Rules Engine:

JSON

01{

02 "name": "My Rule",

03 "phase": "request",

04 "behaviors": [

05 { "name": "set_origin", "target": "123" },

06 { "name": "redirect_to_https", "target": true }

07 ],

08 "criteria": [

09 [

10 { "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/path" }

11 ]

12 ],

13 "order": 1,

14 "description": "Rule description"

15}

API v4 Rules Engine:

JSON

01{

02 "name": "My Rule",

03 "active": true,

04 "behaviors": [

05 { "type": "set_edge_connector", "attributes": { "value": "456" } },

06 { "type": "redirect_https", "attributes": { "enabled": true } }

07 ],

08 "criteria": [

09 { "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/path" }

10 ],

11 "description": "Rule description"

12}

Key Behavioral Differences

Aspect	API v3	API v4
Endpoint path	`/rules_engine/{phase}/rules`	`/{phase}_rules`
Behavior format	`{ "name": "...", "target": "..." }`	`{ "type": "...", "attributes": { ... } }`
Criteria format	Nested arrays `[[{...}]]`	Flat array `[{...}]`
Criteria argument	`input_value`	`argument`
Set Origin behavior	`set_origin`	`set_edge_connector`
Order field	Explicit `order` field	Implicit ordering by creation

Creation Flow Comparison

This section illustrates the step-by-step creation flow for a complete application setup.

API v3 Creation Flow (4 requests)

Create Application:

Shell
01POST /edge_applications
02{ "name": "My App", "delivery_protocol": "http,https" }
Create Domain:

Shell
01POST /domains
02{ "name": "My Domain", "edge_application_id": <app_id> }
Create Origin:

Shell
01POST /edge_applications/<app_id>/origins
02{ "name": "My Origin", "origin_type": "single_origin", "addresses": [...] }
Create Rule to activate Origin:

Shell
01POST /edge_applications/<app_id>/rules_engine/request/rules
02{ "behaviors": [{ "name": "set_origin", "target": <origin_id> }] }

API v4 Creation Flow (5 requests)

Create Application:

Shell
01POST /edge_application/applications
02{ "name": "My App" }
Create Workload:

Shell
01POST /workspace/workloads
02{ "name": "My Workload", "infrastructure": 1 }
Create Workload Deployment:

Shell
01POST /workspace/workloads/<workload_id>/deployments
02{ "strategy": { "type": "default", "attributes": { "edge_application": <app_id> } } }
Create Connector:

Shell
01POST /edge_connector/connectors
02{ "name": "My Connector", "type": "http", "attributes": {...} }
Create Rule to activate Connector:

Shell
01POST /edge_application/applications/<app_id>/request_rules
02{ "behaviors": [{ "type": "set_edge_connector", "attributes": { "value": <connector_id> } }] }

Billing Implications by Endpoint

Endpoint Change	Billing Impact
Domains → Workloads	Requests and Data Transfer metered per Workload instead of per Application
Origins → Connectors	Load Balancer Data Transfer now only measures edge-to-origin traffic, not all Application traffic
Error Responses → Custom Pages	No direct billing impact; depends on Connector usage
Rules Engine	No direct billing impact

Workloads

Azion has adopted the Workload concept to centralize application logic, separating business rules from infrastructure. This enables, reuse, and consistent policy application across environments, following a model inspired by Kubernetes.

Workloads replace Azion Domains. All settings previously managed in Azion Domains are now organized under Workloads.

Operational Changes and User-Facing Impact

The following settings have moved from Azion Domains to Workloads.

Setting	Previous Location	New Location in v4
Environment Type	Domains	Workload > Infrastructure
Domain Settings	Domains	Workload > Domains
Applications	Domains > Settings	Workload > Deployment Settings
Firewall	Domains > Settings	Workload > Deployment Settings
CNAME (text input box)	Domains > Settings	Workload > Domains
Digital Certificate	Domains > Settings	Workload > Protocol Settings
CNAME Access Only	Domains > Settings	Workload > Domains
mTLS (Mutual TLS) Settings	Domains	Workload > Mutual Authentication Settings

Delivery Settings previously configured within an Applications can now be found in Workloads under Protocol Settings:

Protocol Settings
Delivery Ports
Minimum TLS version
TLS Ciphers

Notable Behavioral Changes

CNAME Access Only
- Previous behavior: When enabled, the application could only be accessed via CNAME (for example, app.example.com).
- New behavior: Replaced by “Workload Domain Allow Access,” enabling access through the auto-generated workload URL (for example, xxxxxxxx.map.azionedge.net).

API Usage

Each Workload is implicitly associated with a Deployment. The Deployment defines the relationship between the Workload and the Applications (mandatory), as well as optional components such as Firewall and Custom Pages.

When creating a Workload via the API, you must also create a Workload Deployment to bind the Workload to an Applications. This association ensures that the Workload is correctly linked to the intended Applications.

When using the Console, this association is created automatically when you select Deployment Settings.

Example requests

Creating a Workload:

Shell

curl --request POST --url https://api.azion.com/v4/workspace/workloads --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02"name": "Example Workload",

03"active": true,

04"infrastructure": 1,

05"protocols": {

06 "http": {

07 "versions": [

08 "http1",

09 "http2"

10 ]

11 }

12},

13"workload_domain_allow_access": true

14}

Creating a Workload Deployment:

Shell

curl --request POST --url https://api.azion.com/v4/workspace/workloads/<workload_id>/deployments --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02"name": "Workload Deployment Example",

03"current": true,

04"active": true,

05"strategy": {

06 "type": "default",

07 "attributes": {

08 "edge_application": <edge_application_id>

09 }

10}

11}

For more information about the API parameters visit the Workloads API reference.

Existing Domains

Domains will be automatically converted to Workloads in phases, ensuring compatibility with the original configurations. The migration will occur in waves.

After your account is migrated you will not be able to create new Domains.

Required action

If you have an automation that uses the Domains API endpoints you must update it to use v4 Workloads endpoints.

New Features

Custom Pages: Replaces and expands on the previous Error Responses feature. More details are provided below.
Azion Custom Domain: You to set up a Azion Custom Domain for your application using the format example.azion.app.

Migration Benefits

Improved Organization: Logically group all resources related to an application or service into a single unit (Workload), making management, visualization, and navigation more efficient. This structure creates clear relationships between components.
Scalability and Flexibility: Simplifies deployment, updates, and scaling of complex applications by allowing all required components to be managed as part of a Workload.
Simplified Management: Centralizes configuration and control of different application elements, reducing operational complexity.
Foundation for New Capabilities: Required for future features such as configuration versioning and more intuitive service connections, for example, linking a domain directly to Object Storage without relying on an Applications.

Visit the Workloads Reference

Connectors

Connectors centralizes backend connection settings, allowing you to reuse them across multiple applications, and provides granular control over performance, security, and routing through a unified interface for connecting Applications to an origin (your data source), natively incorporating features such as load balancing, HMAC authentication, and Origin Shield.

Connectors* replaces Applications’s Origin settings. All settings previously managed in Applications Origins tab are now organized under Connectors.

Operational Changes and User-Facing Impact

All settings previously managed in Applications Origins tab are now organized under Connectors.

Setting	Previous Location	New Location in v4
Type	Applications > Origins > Host Settings	Connector Type
Protocol Policy	Applications > Origins > Host Settings	Connector Options > Transport Protocol Policy
Host Header	Applications > Origins > Host Settings	Connector Options > Host
Address	Applications > Origins > Host Settings	Connector Options > Address Management > Address
Path	Applications > Origins > Host Settings	Connector Options > Path
HMAC Authentication	Applications > Origins > Host Settings	HMAC
Connection Timeout	Applications > Origins > Host Settings > Timeouts	Load Balancer Configuration > Connection Timeout
Between Bytes Timeout	Applications > Origins > Host Settings > Timeouts	Load Balancer Configuration > Read/Write Timeout

Notable Behavioral Changes

Connector Type
- Previous behavior: Options included Single Origin and Load Balancer. This defined whether you could configure one or multiple origins.
- New behavior: Single Origin and Load Balancer types have been unified into the HTTP type. When using multiple origins, you must enable Load Balancer to add more origins.
HMAC Authentication
- Previous behavior: Availiable when configuring an Origin.
- New behavior: You must enable Origin Shield when configuring an HTTP type connector.
Timeouts
- Previous behavior: Connection Timeout and Between Bytes Timeout had fixed values.
- New behavior: Now you can configure Connection Timeout and Read/Write Timeout values in the Load Balancer Configuration section of the connector.

API Usage

You can manage Connectorss and their configuration through the API using the available v4 endpoints. Refer to the API reference for details on supported operations and parameters.

Example requests

Creating a connector with the Object Storage Connector Type:

Shell

curl --request POST --url https://api.azion.com/v4/edge_connector/connectors --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02"name": "object storage connector",

03"active": true,

04"type": "edge_storage",

05"attributes": {

06 "bucket": "app-origin",

07 "prefix": "/"

08}

Creating a connector with the HTTP Connector Type:

Shell

curl --request POST --url https://api.azion.com/v4/edge_connector/connectors --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02 "name": "example.com",

03 "active": true,

04 "type": "http",

05 "attributes": {

06 "addresses": [

07 {

08 "active": true,

09 "address": "example.com",

10 "http_port": 80,

11 "https_port": 443,

12 "modules": null

13 }

14 ],

15 "connection_options": {

16 "dns_resolution": "preserve",

17 "transport_policy": "preserve",

18 "http_version_policy": "http1_1",

19 "host": "example.com",

20 "path_prefix": "/",

21 "following_redirect": true,

22 "real_ip_header": "X-Real-IP",

23 "real_port_header": "X-Real-PORT"

24 },

25 "modules": {

26 "load_balancer": {

27 "enabled": false,

28 "config": null

29 },

30 "origin_shield": {

31 "enabled": false,

32 "config": null

33 }

34 }

35 }

36}

For more information about the API parameters visit the Connectors API reference.

Existing Origins

Existing Origins will be migrated according to a schedule, which will be communicated for each case. The migration will occur in phases.

Required action

If you have an automation that uses the Applications - Origins API endpoints you must update it to use v4 endpoints.

New Features

Configuration reusability: The same Connectors can be can be connected to multiple Applications.
Configurable timeouts Connection Timeout and Read/Write Timeout values can be configured in the Load Balancer Configuration section of the Connectors.

Migration Benefits

Simplified Backend Management: Connectors centralizes all backend connection definitions, reducing configuration complexity. Multiple Applications can use a single Connectors, streamlining maintenance and ensuring configuration consistency.
Future-Ready Architecture: Connectors provides the foundation for upcoming Azion Web Platform features and optimizations, ensuring your Applications are ready to use new capabilities as they become available.

Visit the Connectors reference

Custom Pages

Custom Pages is an Azion feature that allows you to customize error pages for users based on the status code received from an Connectors when fetching the content from your origin.

Custom Pages* replaces Applications’s Error Responses settings. All settings previously managed in Applications’ Error Responses tab are now organized under Custom Pages.

Operational Changes and User-Facing Impact

All settings previously managed in Edge Aplications Error Responses tab are now organized under Custom Pages.

Setting	Previous Location	New Location in v4
Default Error Response	Applications > Error Responses	Custom Pages > Page Codes
Custom Error Response	Applications > Error Responses	Custom Pages
Status Code	Applications > Error Responses > Custom Error	Custom Pages > Status Configuration > Page Code
Page Path	Applications > Error Responses > Custom Error	Custom Pages > Response Details > Page Path (URI)
Default Response TTL	Applications > Error Responses > Custom Error	Custom Pages > Response Details > Response TTL
Set Origin	Applications > Error Responses > Set Origin	Custom Pages > Response Details > Page Path (URI)

Notable Behavioral Changes

Relationship
- Previous behavior: Error pages were a part of an Applications.
- New behavior: Custom Pages are separate resources and are linked to a Workload.
Connectors per Page Code
- Previous behavior: All error responses had to have the same Origin.
- New behavior: You can now assign a specific Connectors to each error response page code in Custom Pages. This allows you to customize the response for each error code individually.

API Usage

You can manage Custom Pages and their configuration through the API using the available v4 endpoints. Refer to the API reference for details on supported operations and parameters.

To use a Custom Page, you must link it to a Workload using the Workload deployment endpoint. When using the Console, this association is created under a Workload’s deployment setting.

Example requests

Creating a Custom Page:

Shell

curl --request POST --url https://api.azion.com/v4/workspace/custom_pages --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02"name": "401 error page",

03"active": true,

04"pages": [

05 {

06 "code": "401",

07 "page": {

08 "type": "page_connector",

09 "attributes": {

10 "connector": <edge_connector_id>,

11 "ttl": 300,

12 "uri": "/path/error_page.html",

13 "custom_status_code": 100

14 }

15 }

16 }

17]

18}

Binding a Custom Page to a Workload Deployment:

Shell

curl --request POST --url https://api.azion.com/v4/workspace/workloads/<workload_id>/deployments --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' --data {

02"name": "Workload Deployment Example",

03"current": true,

04"active": true,

05"strategy": {

06 "type": "default",

07 "attributes": {

08 "edge_application": <edge_application_id>

09 "custom_page": <custom_page_id>

10 }

11}

12}

For more information about the API parameters visit the Custom Pages API reference.

Existing Error Responses

Existing Error Responses will be automatically converted to Custom Pages in phases, maintaining compatibility with the original configurations. The migration will occur in waves.

New Features

Response Details: Customize the response for an status code. Specify the URI, status code, TTL to be returned to the client.
Per-Status Code Connectors Assignment Assign a specific Connectors to each error response page code in Custom Pages. This allows you to customize the response for each error code individually.

Migration Benefits

Comprehensive Configuration Options:
- Define a custom status code for each page.
- Set the response Time to Live (TTL).
- Specify the path to the custom page.
- Link each custom page to one or more Connectorss.
Activation and Management:
- Enable or disable any Custom Page using a status toggle.
- View and manage a paginated list of all configured status codes through the user interface.

Visit the Custom Pages Reference

Planned migration timeline

The migration process will occur over the next six months.

Recommendations

Here are recommended actions to ensure a smooth migration:

Monitor Azion communications: Stay informed about migration dates, guides, and any tools provided for the transition.
Plan your migration: Assess how your current settings will fit into the new structure and strategically plan the migration of your resources.
Prepare your team: Ensure your team understands the Workloads concept and its impact on application development and deployment on the Azion Web Platform.
Test new features: As the new features are implemented, test the new capabilities to optimize your applications and services.

Q&A

Test the new features

New Developer accounts will have access to the updated features. To evaluate these features, you can create a personal account that is not associated with your organization’s account. This allows you to test the new functionality independently.

Required actions

Most users will not need to take any action, as the migration process is automatic and preserves existing configurations. However, if you use custom automation, scripts, or CI/CD pipelines that interact with the previous API endpoints, you must update them to use the new v4 endpoints. Review your integrations to ensure compatibility after migration.

Assistance

You can contact our support team or ask Azion Copilot.