APIZ guide

Choose And Operate A Policy

Policy is optional. Add it when a Client Binding is still broader than the job the agent should perform. Both Policy types use the same fail-closed lifecycle:

Working Draft -> credential-free Fixtures -> Published Revision
              -> published suite passes -> Enable -> Attach

Editing or testing a Working Draft does not change live traffic. Publishing does not enable or attach it. Each transition is explicit.

Choose Structured Or Scripted

Need	Structured Policy	Scripted Policy
Guided authoring without code	Best choice	No
Match adapter action, method, resource, tags, origin, or Geo	Yes, when exposed by the descriptor	Yes
Simple allow/deny/reply/rate-limit outcome	Yes	Yes
Inspect or rewrite the logical request	Limited to supported structured parameters	Yes, through the bounded request API
Return a synthetic response	When supported by the structured outcome	Yes
Custom branching or combined conditions	Limited	Yes
Runtime error behavior	Deny	Deny

Start with Structured Policy. Choose Scripted Policy only when the task cannot be expressed clearly with guided fields.

If the requirement is simply “accept this API only from these source networks,” configure the API Instance IP and Geo filtering first. The API Instance IP allowlist is evaluated before Policy and cannot be overridden by an allow decision.

Detailed Tutorials

Structured Policy tutorial: allow General API reads and deny writes with WHEN / THEN / OTHERWISE.
Scripted Policy tutorial: inspect, rewrite, or answer a General API request using bounded TypeScript.

Each tutorial has separate Web Console and CLI procedures and ends with attachment, live verification, and Access Log evidence.

Attachment Order

A Client Binding Policy affects one Client-to-API route and runs first.
An API Instance Policy affects every request reaching the API Instance and runs afterward.
Policies at the same layer run in ascending execution order.
A required Policy always runs. An optional Policy may be skipped only by an earlier decision that explicitly requests it.

For a first Policy, attach it to one Client Binding with order 100. Move a rule to the API Instance layer only when it should apply to every Client using that upstream connection.

Fixture Safety

Policy Fixtures contain synthetic requests and expected decisions. They never resolve an upstream credential or send traffic upstream. Do not paste tokens, cookies, ciphertext, customer payloads, private logs, or production requests into a Fixture.

See Writing Policy Fixtures for the complete Fixture contract.