AFFIXIO
REST and SDK
REST and SDK paths for signed allow or deny
Most teams wire AffixIO through REST or the Node.js SDK. Both paths issue and verify proofs that return ML-DSA-65 signed allow or deny with Merkle audit references, without standing up a PII database at the verifier.
Definition
REST and SDK integration is how applications call AffixIO to issue proofs and verify signed allow or deny at policy boundaries.
Field note. Custom verify wrappers drift from production policy. Use the SDK verify path as the single source of gate truth.
Recommended path
Open the sandbox. Issue a proof. Verify it. Then map the same calls into your service with the official SDK or OpenAPI client. Docs cover quickstart, errors, and integration patterns.
Portals help operations. MCP helps agent tools. Core verification remains issue and verify.
Production hardening
Handle deny explicitly. Persist Merkle refs. Configure zero PII retention. Monitor verify latency beside other authorisation calls.
Procurement packs and evaluate pages cover buyer steps after the technical proof works.
Operational detail for REST and SDK verification
Place issue at consent or policy satisfaction, then verify at the first external boundary. Deny should return a stable code for support. Allow should attach Merkle metadata to the record your finance or ops team already stores.
When WAN is unreliable, run local verify with cached keys and sync Merkle inclusion later. Offline QR and edge agents use the same spent-proof rules as online gates.
Deepfake vector
Unclear integration entry points
Buyers ask whether they need a connector, a portal, or raw HTTP. The answer is usually REST or SDK first, with MCP only where agent tools require it.
Overbuilding connectors
Teams invent frameworks before trying sandbox verify.
Ignoring OpenAPI
Hand-written clients drift from the contract.
Skipping deny handling
Happy-path only integrations fail in production.
Field approach
REST and SDK paths for signed allow or deny
Engineering teams need verify endpoints that fit REST and SDK integrations without bespoke protocol work. AffixIO returns signed allow or deny with Merkle audit refs your services consume directly.
Sandbox prove
Issue and verify once.
Choose REST or SDK
Based on your stack.
Wire deny and audit
Not only allow.
Promote credentials
From sandbox to production carefully.
Verifier audit
Readiness checks for REST and SDK verification
- Complete sandbox happy path and deny path.
- Generate client from OpenAPI or use SDK.
- Persist audit references.
- Read /docs/quickstart and /docs/errors.
- Schedule evaluate conversation when ready.
Operator FAQ
Questions on REST and SDK verification
Is there a Postman collection?
OpenAPI and Postman artefacts are published on the site.
Node only?
SDK focuses on Node.js. REST works from any language.
MCP instead of REST?
Use MCP for agent tool gates. Many backends still call REST.
Where is OpenAPI?
/openapi.json
Further reading
Pages that support REST and SDK verification
Infrastructure
More infrastructure briefs
Integrate REST and SDK verify
Call issue and verify via SDK in sandbox, then promote the same endpoints to your production boundary.