← Production Center

Runtime integration · contract v2

Vordence runs independently. n8n, Make and custom code are optional callers. Enforcement protects only effects routed through this API; it cannot intercept a workflow that bypasses it.

1. Test the connection

POST /api/v1/actions
Authorization: Bearer vd_live_...

{"operation":"connection_test"}

This checks workspace authorization without performing an external effect.

2. Evaluate the exact request

POST /api/v1/actions
Authorization: Bearer vd_live_...
Content-Type: application/json

{"externalId":"unique-job-1042","agentId":"agt_...","action":"send_email","target":"client@example.com","amountCents":0,"parameters":{"subject":"Exact approved subject"}}

Possible decisions: allowed, observed, held, blocked. These are evaluations, not proof of execution. Hold pauses the flow; poll GET /api/v1/actions/:id until effectiveDecision is allowed. Block stops it. A repeated externalId must have identical agent, action, target, parameters and amount; changed requests return 409.

3. Claim authorization immediately before the effect

POST /api/v1/actions
{"operation":"authorize_execution","actionId":"act_..."}

// Continue ONLY after HTTP 200, decision === "allowed",
// oneShot === true, and before executeBefore.
// Never automatically retry the external effect.

Every effect, including observe-mode flows, must pass this one-shot guard. Current permit integrity, permitted action category, per-action financial ceiling, agent state, policy versions and unexpired exact-action approval are rechecked. A lost response is an unknown outcome, not permission to repeat the effect. Use the action ID as the destination's idempotency key wherever supported.

4. Perform the effect once and report its real result

POST /api/v1/actions
{"operation":"record_effect","actionId":"act_...","effectStatus":"executed","evidence":"Destination record ID or run ID"}

Failed or cancelled outcomes can also be reported. The original decision hash remains unchanged; authorization and effect records have separate append-only events. If reporting fails after the destination succeeds, retry reporting only. External execution is reported by the caller, not independently attested by Vordence.

n8n HTTP nodes

  1. Store API key in Header Auth credentials—not workflow JSON.
  2. POST evaluate; Switch blocked / held / allowed / observed.
  3. Wait plus GET poll for held approvals; set a finite timeout.
  4. POST authorize_execution with retries off; stop on any non-200.
  5. Your effect node executes once with destination idempotency.
  6. POST record_effect; reconcile destination before any repeat.

Make HTTP modules

  1. Use a secured connection for the Bearer key.
  2. POST evaluate; Router filters decisions.
  3. Sleep and poll held requests with a finite deadline.
  4. POST authorize_execution immediately before the effect.
  5. Only the allowed route reaches the real effect module.
  6. Do not use automatic retries across an unknown external outcome.

Download the server-side adapter

Download JavaScript adapter
import { Vordence } from './vordence-runtime.mjs';
const permit = new Vordence({ origin: process.env.VORDENCE_ORIGIN, apiKey: process.env.VORDENCE_KEY });
await permit.connectionTest();
const { action } = await permit.evaluate(exactRequest);
// Pause and obtain approval first if action.decision === 'held'.
await permit.execute(action.id, ({externalIdempotencyKey}) => yourEffect(externalIdempotencyKey));

The adapter is server-side only. n8n/Make module configurations above are recipes, not independently validated importable blueprints.

Webhook and maintenance operations

Deliveries are queued durably and retried up to six attempts with backoff and a lease. After exhaustion they enter dead_letter. Use Production Center's Process queued deliveries button when the signing secret is configured. There is no active unattended scheduler in this release. Verify HMAC-SHA256 over the raw body using x-vordence-signature; deduplicate using x-vordence-delivery. Receivers must be idempotent.

Retention clears old delivery payloads while retaining evidence hashes. Workspace deletion requires a seven-day cancellation window and a second explicit owner confirmation; it is not performed by a delivery button. Deleted data cannot be restored through the app.

Team operations →Verify evidence →