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
| Field | Required | Meaning and validation |
|---|---|---|
code | Yes | Exact 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.
Related actions
- 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.