Applications
How the azion/applications functions authenticate, the envelope they answer with, the errors they report, and the page that documents each resource.
The azion/applications module is the Azion Lib library for Applications. Its functions create, list, read, update, and delete applications. Inside an application, they manage its origins, cache settings, device groups, function instances, and rules. The module calls Azion API v3, and each function takes one object argument.
Install the package:
The azion package receives bug fixes only, and its maintenance ends in December 2026.
The samples in this section are ES modules that use top-level await, and they run in Node.js. Most of them are TypeScript. A sample whose payload TypeScript rejects is JavaScript, and its section names the type that rejects it.
Authentication
Functions that you import and call directly read your personal token from the AZION_TOKEN environment variable. A client from createAzionApplicationClient carries the token in its token field.
| Variable | Description |
|---|---|
AZION_TOKEN | Your Azion personal token. |
AZION_DEBUG | With true, turns on debug mode. |
For more information, refer to How Azion Lib works.
Response envelope
The azion/applications functions report a failure in one of two ways, depending on the object they act on:
- The application-level functions createApplication, getApplications, getApplication, patchApplication, and putApplication return
{ data }on success. When the API answers with an error status, they throwError: HTTP error! Status: <code> - <TEXT>, so call them insidetry/catch. - deleteApplication and the functions for origins, cache settings, device groups, function instances, and rules do not throw. They return an AzionApplicationResponse,
{ data?, error? }. On failure,errorholds{ message, operation }, whereoperationnames the call, such asget origin.
The samples for the application-level functions destructure error as well. On a failed request, those functions throw before the sample checks it.
A delete that succeeds still returns { error: { message: 'Expected JSON response, but got: ', operation } }. The API answers a delete with an empty body, which the module reads as an error. The envelope cannot tell a successful delete from a failed one, so each delete sample on this page reads the object back. A 404 answer confirms the delete.
Functions by resource
The module groups its functions by the object they manage. An application is addressed by applicationId, which every function except createApplication and getApplications takes. Rules also take a phase, and an origin is addressed by its originKey, a UUID.
An application that createApplication or getApplication returns also carries the functions of the five sub-resources as application methods.
Errors
The application-level functions throw these messages inside an Error. The other functions return them in error.message, and error.operation names the call, such as create device group.
| Message | Cause | What to do |
|---|---|---|
HTTP error! Status: 401 - UNAUTHORIZED | No valid token reached the call: AZION_TOKEN is unset or holds an invalid token, and no client token was passed. | Set AZION_TOKEN to a valid personal token, or pass token to createAzionApplicationClient. |
HTTP error! Status: 404 - NOT FOUND | No application has that ID, or the application holds no object with that ID or origin key. | Check the ID with the matching list function, such as getApplications or getOrigins. |
HTTP error! Status: 400 - BAD REQUEST | API v3 refused the payload. The message does not carry the reason the API gives. Causes include application_acceleration in a create request, a cache setting on an application with no origin, a device group name with a space or a hyphen, and sort or order in a cache setting list. | Compare the payload with the section of the function you called, and remove or change the field it names. |
Expected JSON response, but got: | A delete succeeded, and the API answered with an empty body. | Read the object back. A 404 error confirms the delete. |