Topolo Docs Topolo Platform
Open workspace

Check code eligibility — Campaigns

Evaluates a code and returns HTTP 200 with valid:true or valid:false and a reason. This read does not consume redemption capacity.

Check code eligibility

Evaluates a code and returns HTTP 200 with valid:true or valid:false and a reason. This read does not consume redemption capacity.

Outcome and boundaries

Evaluates a code and returns HTTP 200 with valid:true or valid:false and a reason. This read does not consume redemption capacity.

Checks code status, campaign active status, offer validFrom/validTo and overall maxRedemptions. It does not check maxPerUser, minPurchase or a customer identity in this action.

Before you start

  • Confirm the intended environment and current credential organization using whoami; discover the exact application/action before any call.
  • Required application permission: app_topolo_campaigns.redemptions:redeem. Catalog discoverability is not permission to execute.
  • Discover an authorized canonical workspace and bind resourceType workspace/resourceId separately from action input.
  • All worked cases in this guide are hypothetical source-reviewed illustrations; no business action, live fixture, customer data or provider request was executed.
  • Canonical workspace minimum access is read in addition to the application permission. After grant verification, the first request may create an app-local identity/recipient mirror even before the later app-permission check; this is not campaign-domain completion.

Discover the intended identifiers

  • Read codes.list and use the exact code string; preserve the intended organization/workspace.

Action: app_topolo_campaigns.codes.validate · GET /api/codes/{code}/validate.

Input fields

FieldRequiredMeaning and validation
codeYesExact human-readable code string. It is not the code-record id and not a provider payment id. string; minLength=1

Safe call sequence

Write the reviewed input to payload.json; fixture identifiers below are unusable examples. Validate before planning, bind the discovered resource separately, and execute only within actual authority.

topolo actions validate app_topolo_campaigns.codes.validate --data @payload.json --json
topolo actions plan app_topolo_campaigns.codes.validate --resource-type workspace --resource-id "$CAMPAIGNS_WORKSPACE_ID" --data @payload.json --json

A published read can use topolo actions call with the same discovered resource and input. This guide does not invoke it.

Worked cases

Every response below is synthetic and source-reviewed, not captured. HTTP status and body are explained independently; a structurally valid body alone never proves successful execution. Middleware may add a different error envelope.

Eligible code · HTTP 200

Input:

{
  "code": "EXAMPLE-20"
}

Illustrative response:

{
  "valid": true,
  "code": {
    "id": "code_example",
    "campaignId": "campaign_example",
    "batchId": null,
    "code": "EXAMPLE-20",
    "ownerRef": null,
    "quroSlug": null,
    "status": "active",
    "createdAt": "2026-10-20T00:00:00.000Z"
  },
  "campaign": {
    "id": "campaign_example",
    "type": "event",
    "name": "Illustrative launch",
    "status": "active",
    "offerId": null,
    "commission": null,
    "attribution": {},
    "createdAt": "2026-10-20T00:00:00.000Z",
    "updatedAt": "2026-10-20T00:00:00.000Z"
  },
  "offer": null,
  "ownerRef": null
}

Unknown code is a normal negative result · HTTP 200

Input:

{
  "code": "EXAMPLE-ABSENT"
}

Illustrative response:

{
  "valid": false,
  "reason": "code_not_found"
}

Disabled code · HTTP 200

Input:

{
  "code": "EXAMPLE-20"
}

Illustrative response:

{
  "valid": false,
  "reason": "code_disabled",
  "code": {
    "id": "code_example",
    "campaignId": "campaign_example",
    "batchId": null,
    "code": "EXAMPLE-20",
    "ownerRef": null,
    "quroSlug": null,
    "status": "disabled",
    "createdAt": "2026-10-20T00:00:00.000Z"
  }
}

Verify the outcome

  • Inspect valid and reason, not HTTP success alone. Validity is a point-in-time check, not a reservation or proof a subsequent redemption will succeed.

Refusals and recovery

  • HTTP 403 forbidden: Raw handler permission refusal. SDKs can normalize it to permission_denied. Keep the same intended resource; do not widen access.
  • HTTP 403 workspace_forbidden: The canonical workspace grant refused the selected resource. Resolve it with the access owner, not a guessed workspace.

No campaign-domain rollback is needed for this read. Preserve authentication, permission and resource refusals; do not switch organization or widen a grant to bypass them.

Exact schemas and provenance

Input schema:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "code": {
      "type": "string",
      "minLength": 1
    }
  },
  "required": [
    "code"
  ],
  "additionalProperties": false
}

Output schema:

{
  "type": "object",
  "title": "Validate a code response",
  "description": "Operation result returned by codes.validate.",
  "properties": {
    "success": {
      "type": "boolean"
    },
    "id": {
      "type": "string"
    },
    "data": {
      "anyOf": [
        {
          "type": "object",
          "title": "code record",
          "properties": {
            "id": {
              "type": "string",
              "description": "Stable identifier when the code exposes one."
            }
          },
          "additionalProperties": true
        },
        {
          "type": "object",
          "additionalProperties": true
        }
      ]
    },
    "result": {
      "type": "object",
      "additionalProperties": true
    },
    "message": {
      "type": "string"
    }
  },
  "additionalProperties": true,
  "x-topolo-contract-source": "derived-action-metadata",
  "x-topolo-contract-precision": "structural"
}

Reviewed immutable source: TopoloCampaigns@cacbb8b12b4e19a662cf82d03a927aef3c3a35e8, apps/api/src/campaigns-store.ts. Fresh production catalog was read on 2026-10-20. Its publication metadata is not proof that this source is loaded. Output examples are not widened or rewritten to force schema success; the accompanying validation record classifies exact success, refusal, no-body and structural-schema limits.

  • List issued codes — Campaigns: Lists code records in the bound organization/workspace, optionally filtered by campaignId; results are ordered newest creation first.
  • Record a code redemption — Campaigns: Evaluates and records a redemption, consuming the stored overall/per-user limit where enforced. This is a write, not a validation read, discount delivery, payment charge or commission payout.

Local input rejection example

This deliberately invalid input belongs to a pure schema check; it is never a planned or executed request. The closed action input schema must reject the extra field. It has no HTTP status or server response.

{
  "code": "EXAMPLE-20",
  "__unsupported_field": true
}

The hidden companion labels this as ILLUSTRATIVE_LOCAL_SCHEMA_CHECK; its validation representation is not an action output.

Published output validation limits

Current published output qualification: the output schema accepts an empty object, a partial success marker, a partial data object and a refusal body. It therefore establishes only broad structure. Require the documented HTTP/domain result and source-shaped fields; missing fields or a schema-valid error are not success.

These observations come from pure checks of the exact published schema; they are not server responses or production captures.