Lesson 06 · outer fringe

Why Isn't It Serving?

Intent and effect are different fields. Five of them, spread unevenly across four entities, and the one you most want — "is this ad actually running, and if not why" — is a read-only array that is absent when the answer is yes.

≈15 min · pinned to li-lms-2026-08

The one distinction that organises everything

Every status-shaped field in this API is on one side of a line:

The docs say it plainly for campaigns: servingStatuses is an array "that determine whether or not a campaign can be served; unlike status, which is user-managed, the values are controlled by the service."

If you take one thing: a PATCH that sets status: ACTIVE and returns 200 has told you nothing about whether an ad will run. Intent succeeded. Effect is a separate question, answered by a separate read, at a later time.

Which entity exposes what

This is the part that cannot be guessed, and the part where Meta's model actively misleads: there, every level has an effective_status. Here the fields are inconsistent by level.

The hold reasons cascade downward

Here is the payoff, and the thing that makes the vocabulary genuinely useful rather than merely verbose. A creative's servingHoldReasons contains not just its own problems but its ancestors'. The array is a flattened diagnosis of the whole chain above it.

graph TD
  A["Ad Account"] -->|"ACCOUNT_SERVING_HOLD
ACCOUNT_TOTAL_BUDGET_HOLD
ACCOUNT_END_DATE_HOLD"| G
  G["Campaign Group"] -->|"CAMPAIGN_GROUP_STATUS_HOLD
CAMPAIGN_GROUP_START_DATE_HOLD
CAMPAIGN_GROUP_END_DATE_HOLD
CAMPAIGN_GROUP_TOTAL_BUDGET_HOLD"| C
  C["Campaign"] -->|"CAMPAIGN_STOPPED
CAMPAIGN_START_DATE_HOLD
CAMPAIGN_END_DATE_HOLD
CAMPAIGN_TOTAL_BUDGET_HOLD
CAMPAIGN_AUDIENCE_COUNT_HOLD"| R
  R["Creative
servingHoldReasons"]
  R --- O["own reasons:
STOPPED · UNDER_REVIEW · REJECTED
PROCESSING · PROCESSING_FAILED
FORM_HOLD · JOB_POSTING_ON_HOLD
JOB_POSTING_INVALID
REFERRED_CONTENT_QUALITY_HOLD"]

  classDef lvl fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
  classDef own fill:#fef3c7,stroke:#d97706,color:#78350f
  class A,G,C,R lvl
  class O own

Read the prefixes as addresses. ACCOUNT_* means go fix the account; CAMPAIGN_GROUP_* means the layer you were tempted to skip in Lesson 01 is now the reason nothing runs. The unprefixed ones — STOPPED, UNDER_REVIEW, REJECTED — are the creative's own.

Review is a third axis

A creative can be intendedStatus: ACTIVE, its whole ancestor chain healthy, and still not serve — because a human or a model has not approved it yet. That lives in review, which is read-only and, importantly, absent while the creative is in DRAFT. Review starts when the creative is activated.

NEEDS_REVIEW deserves a note, because its name is a lie about its cause. It does not mean "someone requested a review." The docs: the creative "has been rejected by content model or policy checker or returned by fallback case that auto approval didn't make any decision." It is the uncertain bucket. For your product that means it is not a failure to report to the customer and not a success either — it is a wait, of unbounded length, and you should render it differently from PENDING.

The rejectionReasons list is worth a skim once, not memorising. Its useful property: many codes are about the landing page, not the ad — NONFUNCTIONAL_SITE, MISSING_PRIVACY_POLICY, BACK_BUTTON_NOT_WORKING, INCONSISTENT_DISPLAY_AND_LANDING_PAGE_URLS. A rejection is not always something your customer can fix by editing copy, and your error surface should not imply that it is.

Practice

function isRunning(c: Creative): boolean {  if (c.intendedStatus !== 'ACTIVE') return false  if (c.review?.status !== 'APPROVED') return false  return c.servingHoldReasons.length === 0}

async function pause(id: CreativeUrn) {  const before = await getCreative(id)  if (before.review?.status === 'PENDING') throw new InReviewError()  await patchCreative(id, { intendedStatus: 'PAUSED' })  await db.creatives.update(id, { paused: true })}

const OWN = new Set(['STOPPED', 'UNDER_REVIEW', 'REJECTED', 'PROCESSING',  'PROCESSING_FAILED', 'FORM_HOLD', 'REFERRED_CONTENT_QUALITY_HOLD',  'JOB_POSTING_ON_HOLD', 'JOB_POSTING_INVALID']) function blockers(c: Creative) {  const reasons = c.servingHoldReasons ?? []  const mine = reasons.filter(r => OWN.has(r))  return mine.length ? { level: 'creative', reasons: mine }                     : { level: 'ancestor', reasons }}

{
  "id": "urn:li:sponsoredCreative:120560935",
  "campaign": "urn:li:sponsoredCampaign:360035215",
  "intendedStatus": "ACTIVE",
  "isServing": false,
  "review": { "status": "PENDING" },
  "servingHoldReasons": [
    "UNDER_REVIEW",
    "CAMPAIGN_STOPPED",
    "ACCOUNT_SERVING_HOLD",
    "CAMPAIGN_GROUP_STATUS_HOLD"
  ]
}

Retaining this

1. Intent versus effect. You write status and intendedStatus; the service writes servingStatuses, servingHoldReasons, isServing, review. A 200 on the first tells you nothing about the second.
2. Prefixes are addresses. Diagnosing a non-serving ad is string-prefix arithmetic on one array, then fixing top-down. You do not need any other endpoint to locate the problem.
3. Absent means healthy — and therefore your happy path is the one where the field you are indexing into does not exist. Write that access as ?? [] once, in one place.
4. Tomorrow: from memory, list the four levels of the spine and, for each, the exact name of its status-ish fields. The interesting answer is which level breaks the pattern, and why the rename was honest.

Sources: Create and Manage Creatives (creative schema, CreativeReview, servingHoldReasons, rejection reasons), Create and Manage Campaigns (status, servingStatuses). Version li-lms-2026-08.