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:
| Type | What it is | Details |
|---|---|---|
custom | A SaaS or web application you define by its URLs | Custom applications |
private | A private (internal) application routed through Prisma Access | Private applications |
non-web | A remote connection over RDP or SSH | Non-web applications |
localdesktopcustom | A local desktop application you define by its executables | Desktop applications |
localdesktopcatalog | A local desktop application curated by Palo Alto Networks | Desktop applications |
catalog | A 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, andlocaldesktopcustom. - On
PATCH, for all six types. Oncatalogandlocaldesktopcatalog,classificationandtagIDsare 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:
| Value | Meaning |
|---|---|
Sanctioned | Approved for use in your organization |
Tolerated | Allowed, but not formally approved |
Unsanctioned | Not approved for use |
Unclassified | No 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" ]
}
}'
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.
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
| Limit | Value |
|---|---|
| URLs per application | 100 by default, raised per tenant on request, up to 5000 |
| URLs per tenant (custom + private + non-web, combined) | 15,000 |
| Tags per application | 63 |
| Applications per bulk-create call | 1000 |
| Application IDs per bulk-delete call | 2000 |
| Applications per tag and classification bulk update | 500 |
name length | 255 characters (50 for non-web) |
description length | 2500 characters |
| Custom applications per tenant | 5000 |
| Private applications per tenant | 2000 |
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
| Method | Path | Purpose |
|---|---|---|
GET | /applications | List 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/categories | List 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-update | Set 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-delete | Delete up to 2000 applications atomically |
All paths are under the /seb-api/v1 base.
Tips and gotchas
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.
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.
Related
- Applications: Application catalog, Custom applications, Private applications, Non-web applications, Desktop applications, Application tags, Application groups
- Concepts: Pagination, Delta patch, Draft and publish, Partial publish
- Use cases: Govern URLs with an allow/block list, Bulk-sync a rule's applications
