DLP API: GET /v2/api/{data-patterns,data-profiles}/{id} returns 400 for valid IDs (server-side)

[cdot65]

Summary

After SDK v0.9.2 unblocked DLP list parsing, live tenant validation surfaced that the GET-by-id endpoint for both data-patterns and data-profiles returns HTTP 400 for every ID we've tried — including IDs returned in the same tenant's list response. The matching endpoints for data-filtering-profiles and dictionaries work fine.

This is a server-side issue, not SDK or CLI. Reproducible via raw curl with the same OAuth token. Filing here because the SDK owns the API contract spec (specs/dlp/DataPatterns.yaml, specs/dlp/DataProfiles.yaml) and is best positioned to escalate upstream.

Repro (2026-05-23, live tenant)

OAuth client-credentials token, Accept: application/json:

```bash
curl -s -w "\nHTTP %{http_code}\n" \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json" \
"https://api.dlp.paloaltonetworks.com/v2/api/data-patterns/6900c1e71cc7eba99b07bb43"
```

Response:
```json
{
"type" : "about:blank",
"title" : "Bad Request",
"status" : 400,
"instance" : "/v2/api/data-patterns/6900c1e71cc7eba99b07bb43",
"timestamp" : "2026-05-23T19:39:22.143957555Z"
}
```
HTTP 400.

Same shape for `/v2/api/data-profiles/{id}` (tested with profile id `11995048`, a custom profile owned by this tenant).

What we ruled out

Hypothesis	Verdict
Wrong path	❌ Matches OpenAPI spec (`/v2/api/data-patterns/{resourceId}`) and SDK construction at `src/management/dlp/data-patterns.ts:85-95`
Stale token / wrong scope	❌ Same token works for `list` and for filtering-profiles/dictionaries `get`
Wrong ID format	❌ Tried multiple IDs from `list` response — custom (`6990ab1fe10ca60e300341f3`), predefined (`6900c1e71cc7eba99b07bb43`), profile numeric (`11995048`). All 400.
URL encoding	❌ IDs are plain alphanumeric — `encodeURIComponent` is a no-op
Missing `Accept` header	❌ Tested with explicit `Accept: application/json` — same 400
SDK Zod validation	❌ Server returns 400 before SDK even sees a response body — pre-parsing

The other two DLP GET-by-id endpoints (`data-filtering-profiles`, `dictionaries`) work fine with the same auth + tooling, so it is not a global DLP API outage.

Impact

• CLI `airs runtime dlp patterns get ` and `airs runtime dlp profiles get ` unusable against live tenants (see prisma-airs-cli docs — known-issue note added there)
• Users can still `list` and filter client-side, but cannot fetch a single resource by id

Suggested next step

Escalate to the AIRS / DLP API team. Either the spec is wrong (the endpoint takes a different param) or the server-side handler regressed.

Cross-refs

• prisma-airs-cli PR #78 — DLP CLI commands (this issue surfaced during closeout)
• SDK #160 / #161 — v0.9.2 nullable sweep that unblocked `list` parsing

[cdot65]

Update 2026-05-23 — scope is broader than GET-by-id

Smoke test against the same tenant (CLI v2.9.0, SDK v0.9.2) found three additional DLP endpoints returning the same generic 400 Bad Request with empty problem-detail body. Same fingerprint as the originally-filed GET issue ({type: about:blank, title: Bad Request, status: 400, instance: <path>, timestamp: ...} — no field-level detail).

Expanded matrix

Endpoint	Status	Notes
GET /v2/api/data-patterns/{id}	400	Original report. Also affects custom patterns, not only predefined.
GET /v2/api/data-profiles/{id}	400	Original report.
POST /v2/api/data-profiles	400	New. Reproduced with three body variants (minimal multi_profile, expression_tree with 3-level nesting, verbatim clone of an existing working custom profile). Direct curl repro below.
PATCH /v2/api/data-patterns/{id}	400	New. PATCH against a freshly-created custom pattern (CREATE returned 201; PATCH then returns 400).

What works

• LIST on all four resources (patterns, profiles, dictionaries, filtering-profiles)
• GET on dictionaries and filtering-profiles
• POST on data-patterns ✓
• DELETE (soft-archive) on data-patterns ✓

curl repro for POST /v2/api/data-profiles

Body is a stripped clone of the existing working profile asdfafdsadsa (server-assigned fields removed, new name):

curl -sS -X POST 'https://api.dlp.paloaltonetworks.com/v2/api/data-profiles' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{
    "name": "cli-smoke-clone-20260523-200415",
    "description": "throwaway clone",
    "profile_type": "advanced",
    "detection_rules": [
      {
        "rule_type": "multi_profile",
        "multi_profile": {
          "data_profile_ids": [11995018, 11995012, 11995029],
          "operator_type": "or"
        }
      }
    ]
  }'

Response:

HTTP/1.1 400
content-type: application/problem+json

{
  "type": "about:blank",
  "title": "Bad Request",
  "status": 400,
  "instance": "/v2/api/data-profiles",
  "timestamp": "2026-05-23T20:04:37.106241916Z"
}

Hypothesis

Same root cause as GET-by-id: a validator (or middleware) on this tenant rejecting requests without surfacing the failing constraint. Suggest pulling server logs for instance: /v2/api/data-profiles at the timestamp above to identify the rejecting validator and have it return errors[] per RFC 7807.

Impact

• runtime dlp profiles create|patch|replace all blocked → effectively read-only for profiles via API
• runtime dlp patterns get|patch|replace all blocked → effectively LIST + CREATE + DELETE only

Workarounds (CLI-side)

• profiles list --output json | jq '...' — filter client-side
• Mutations via Strata Cloud Manager UI

@claude — please track the expanded scope here; no SDK/CLI change required.