Skip to main content

Applications

An application is a named object that represents something you want policy to recognize and govern: a SaaS site, a private (internal) application, a non-web remote connection, or a desktop application. You create applications once, then reference them, directly or via an application group, from an access and data rule.

This page covers what is common to every application: the types, tags and classification, how to list and read applications, bulk operations, and shared limits. Each type has its own page for fields, the URL object, create, update, and worked examples.

On this page: types, tags and classification, retrieve, bulk operations, limits, endpoint reference, tips.


Types​

The type determines the shape of the object and which page documents it:

TypeWhat it isDetails
customA SaaS or web application you define by its URLsCustom applications
privateA private (internal) application routed through Prisma AccessPrivate applications
non-webA remote connection over RDP or SSHNon-web applications
localdesktopcustomA local desktop application you define by its executablesDesktop applications
localdesktopcatalogA local desktop application curated by Palo Alto NetworksDesktop applications
catalogA SaaS application from the Universal Application Directory (UAD)Application catalog

Four types are yours to create and edit. Two, catalog and localdesktopcatalog, are curated by Palo Alto Networks: you list them, read them, reference them from a rule, and set their classification and tags, but you cannot create or delete them or change any other field.

Create a dedicated application (or a focused URL list) when it is important to identify that traffic in events with a recognizable name, or to assign policy to it specifically. If you only need broad coverage, a category or an "any" application segment is simpler.


Tags and classification​

Every application, including the catalog types, carries a classification and a list of tags. They are separate fields that serve different purposes: classification records how your organization treats the application, tags are free-form labels you define for your own grouping and reporting.

Both are returned on every read, for every type, and you can set both on every type:

  • On create, for the four types you create: custom, private, non-web, and localdesktopcustom.
  • On PATCH, for all six types. On catalog and localdesktopcatalog, classification and tagIDs are the only fields you can change.
  • On many applications at once, with bulk update: up to 500 applications per call, any type.

Classification​

classification is a single value per application:

ValueMeaning
SanctionedApproved for use in your organization
ToleratedAllowed, but not formally approved
UnsanctionedNot approved for use
UnclassifiedNo classification recorded (the default)

Send classification on create or on PATCH. Unclassified means no classification is recorded rather than a value stored against the application, so setting an application back to Unclassified clears it.

Tags​

Tags are created and managed with their own endpoints (see Application tags). On the application, you only reference them by ID.

Tags are returned on read as objects and written by ID:

"tags": [
{ "id": "0TG01FINANCEAPPROVEDXXXXXXXXX", "name": "Finance approved" },
{ "id": "0TG01PCIINSCOPEXXXXXXXXXXXXXX", "name": "PCI in scope" }
]

On create, send tagIDs as a plain array of tag IDs. A tag ID is 0TG followed by 26 digits and uppercase letters (never I, L, O, or U), and an application holds up to 63 tags:

curl -sS -X POST "$PB_API_BASE/applications/type/custom" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Acme Wiki",
"type": "custom",
"urls": [ { "url": "wiki.acme.example.com" } ],
"classification": "Sanctioned",
"tagIDs": [ "0TG01FINANCEAPPROVEDXXXXXXXXX" ]
}'

On PATCH, tagIDs accepts two forms, the same replace-or-delta pattern the urls field uses (see Delta patch):

  • Replace the whole set: send a plain array. The new list fully replaces the old one.
  • Delta add and remove: send tagIDs: { "add": [...], "remove": [...] } to adjust the set without re-sending it, which avoids overwriting concurrent edits.
curl -sS -X PATCH "$PB_API_BASE/applications/type/custom/$APP_ID" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "custom",
"classification": "Tolerated",
"tagIDs": {
"add": [ "0TG01PCIINSCOPEXXXXXXXXXXXXXX" ],
"remove": [ "0TG01FINANCEAPPROVEDXXXXXXXXX" ]
}
}'
note

Finding a tag ID. List or search tags with GET /applications/tags (preview: send x-prisma-browser-preview: application-tags) to get their IDs, or read an application that already carries the tag and take the ID from its tags array. To create, rename, and delete tags, see Application tags.

On a catalog application, send the catalog type with classification, tagIDs, or both:

curl -sS -X PATCH "$PB_API_BASE/applications/type/catalog/$APP_ID" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "catalog",
"classification": "Sanctioned",
"tagIDs": { "add": [ "0TG01FINANCEAPPROVEDXXXXXXXXX" ] }
}'

Classification and tags never overlap. Classification is stored separately and is never returned in the tags array, so you change it through classification and never by adding a tag named Sanctioned.


Retrieve​

There are two ways to list applications and two ways to read a single one. The response shape depends on the application's type: read the type field first, then the type-specific fields.

List everything returns applications of all types, so it is the right call to export or reconcile your whole inventory. It supports filtering by type, name, url, classification, tagId, and tagName, pagination with limit and cursor, and sort / order (see Pagination). classification, tagId, and tagName take a comma-separated list and match any value; tagId and tagName cannot be combined, and tagName is case-sensitive:

curl -sS -G "$PB_API_BASE/applications" \
-H "Authorization: Bearer $PB_TOKEN" \
--data-urlencode "limit=50"

Response (200). The data array mixes types, so read each item's type field first:

{
"data": [
{
"type": "custom",
"id": "0AP01ACMEWIKIXXXXXXXXXXXXXXXX",
"name": "Acme Wiki",
"category": "Uncategorized",
"classification": "Sanctioned",
"tags": [ { "id": "0TG01F1NANCEAPPR0VEDXXXXXXXXX", "name": "Finance approved" } ],
"metadata": { "createdTime": "2026-01-15T10:00:00Z", "lastUpdatedTime": "2026-01-15T10:00:00Z" },
"urls": [ "*://wiki.acme.example.com/*" ]
},
{
"type": "catalog",
"id": "0AP01CATALOGSSLXXXXXXXXXXXXXX",
"name": "Ssl",
"category": "Encrypted Tunnel",
"classification": "Sanctioned",
"tags": [ { "id": "0TG01F1NANCEAPPR0VEDXXXXXXXXX", "name": "Finance approved" } ],
"metadata": { "createdTime": "2024-04-26T12:48:39Z", "lastUpdatedTime": "2026-01-15T10:00:00Z" },
"urls": [ "*://www.ssllabs.com/*" ],
"catalog_name": "ssl"
}
// ... more applications of any type
],
"metadata": { "configurationVersion": { "id": "0CV01EXAMPLEXXXXXXXXXXXXXXXXX", "status": "draft", "number": 0 } },
"pageInfo": { "hasNextPage": true, "cursor": "gaFpvTBBUDAx...", "totalCount": 72518 }
}

List one type narrows to a single type with the same filters:

curl -sS -G "$PB_API_BASE/applications/type/custom" \
-H "Authorization: Bearer $PB_TOKEN" \
--data-urlencode "name=wiki"

Response (200). Every item is the requested type:

{
"data": [
{
"type": "custom",
"id": "0AP01ACMEWIKIXXXXXXXXXXXXXXXX",
"name": "Acme Wiki",
"description": "",
"category": "Uncategorized",
"classification": "Sanctioned",
"tags": [ { "id": "0TG01F1NANCEAPPR0VEDXXXXXXXXX", "name": "Finance approved" } ],
"metadata": { "createdTime": "2026-01-15T10:00:00Z", "lastUpdatedTime": "2026-01-15T10:00:00Z" },
"urls": [ "*://wiki.acme.example.com/*" ]
}
// ... more custom applications
],
"metadata": { "configurationVersion": { "id": "0CV01EXAMPLEXXXXXXXXXXXXXXXXX", "status": "draft", "number": 0 } },
"pageInfo": { "hasNextPage": false, "cursor": "", "totalCount": 1 }
}

Read one application by ID, either directly or scoped to its type:

curl -sS "$PB_API_BASE/applications/$APP_ID" \
-H "Authorization: Bearer $PB_TOKEN"

Response (200). The fields depend on type (this example is custom):

{
"type": "custom",
"id": "0AP01ACMEWIKIXXXXXXXXXXXXXXXX",
"name": "Acme Wiki",
"category": "Uncategorized",
"classification": "Sanctioned",
"tags": [ { "id": "0TG01F1NANCEAPPR0VEDXXXXXXXXX", "name": "Finance approved" } ],
"metadata": {
"createdTime": "2026-01-15T10:00:00Z",
"lastUpdatedTime": "2026-01-15T10:00:00Z",
"createdBy": "api-service-account",
"lastUpdatedBy": "api-service-account",
"configurationVersion": { "id": "0CV01EXAMPLEXXXXXXXXXXXXXXXXX", "status": "draft", "number": 0 }
},
"urls": [ "*://wiki.acme.example.com/*" ]
}

To discover the valid values for the optional category field:

curl -sS "$PB_API_BASE/applications/categories" \
-H "Authorization: Bearer $PB_TOKEN"

Response (200):

{
"data": [
"Analytics",
"Artificial Intelligence",
"Collaboration",
"Encrypted Tunnel",
"File Sharing",
"Instant Messaging"
// ... more categories
]
}

Bulk operations​

Two bulk endpoints span all creatable types. Both take the same per-type bodies as the single-object endpoints.

Bulk create an array of applications of one type (1 to 1000 per call):

curl -sS -X POST "$PB_API_BASE/applications/bulk-create/custom" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '[
{ "type": "custom", "name": "Allow - Figma", "urls": [ { "url": "figma.com" } ] },
{ "type": "custom", "name": "Allow - Miro", "urls": [ { "url": "miro.com" } ] }
]'

Response (201) is an array of the created applications:

[
{ "id": "0AP01ALLOWFIGMAXXXXXXXXXXXXXX", "name": "Allow - Figma" },
{ "id": "0AP01ALLOWMIROXXXXXXXXXXXXXXX", "name": "Allow - Miro" }
]

Bulk delete by appIds array (1 to 2000 IDs). The operation is atomic: if any ID is invalid, nothing is deleted:

curl -sS -X POST "$PB_API_BASE/applications/bulk-delete" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"appIds": [
"0AP01ACMEWIKIXXXXXXXXXXXXXXXX",
"0AP01ACMEDOCSXXXXXXXXXXXXXXXX"
]
}'

Returns 204 with an empty body. Because the operation is atomic, a single invalid ID returns 400 and deletes nothing.

note

Bulk update covers tags and classification only. To add or remove tags, or set the classification, on up to 500 applications in one call, use bulk update (preview). To change any other field on many applications, send one PATCH per application (each can add or remove URLs with the delta form). To change the applications attached to a rule in bulk, see Bulk-sync a rule's applications.


Limits​

LimitValue
URLs per application100 by default, raised per tenant on request, up to 5000
URLs per tenant (custom + private + non-web, combined)15,000
Tags per application63
Applications per bulk-create call1000
Application IDs per bulk-delete call2000
Applications per tag and classification bulk update500
name length255 characters (50 for non-web)
description length2500 characters
Custom applications per tenant5000
Private applications per tenant2000

Both URL limits return 400 when exceeded. The per-application limit also applies to the add and remove lists on a delta PATCH. Catalog applications do not count against the tenant budget; private application CIDRs do.

Prefer broader patterns over thousands of exact URLs. Remaining per-type limits (CIDRs, executables) are documented on each type's page.

For per-tenant totals and how stored lists are counted, see Entity limits.


Endpoint reference​

MethodPathPurpose
GET/applicationsList applications of all types (filter, paginate)
GET/applications/type/{type}List applications of one type
GET/applications/{id}Read one application
GET/applications/type/{type}/{id}Read one application (scoped to type)
GET/applications/categoriesList available category values
POST/applications/type/{type}Create one application
POST/applications/bulk-create/{type}Create up to 1000 applications
PATCH/applications/type/{type}/{id}Update one application (on catalog types, classification and tags only)
POST/applications/tags/bulk-updateSet tags and classification on up to 500 applications (preview)
DELETE/applications/{id}Delete one application
DELETE/applications/type/{type}/{id}Delete one application (scoped to type)
POST/applications/bulk-deleteDelete up to 2000 applications atomically

All paths are under the /seb-api/v1 base.


Tips and gotchas​

note

Two URL limits, not one. A 400 on a URL write can mean either that the application passed its own limit (100 by default) or that the tenant passed its combined budget of 15,000 URLs across custom, private, and non-web. Read the error message to tell them apart. Prefer broader patterns over thousands of exact URLs.

note

Check the catalog before you create. If the application already exists in the catalog, reference the catalog application instead of recreating it as custom. The same applies to desktop applications: check localdesktopcatalog before defining a localdesktopcustom application, because a custom application that reuses a catalog executable name is rejected. See Application catalog and Desktop applications.