Build with Aarchon Core

Developer Toolkit

Explore the current API surface, test policy rules with sample inputs, copy integration patterns, and download safe starter templates. The interactive tools run in your browser and never send sample inputs or credentials to Aarchon.

Tools and working resources

API reference

Identity, account, administrator, and server-only Policy endpoints, with access requirements and response codes.

Browse endpoint reference

Policy playground

Try clearance, compartment, and action combinations against a local sample of the current default rules.

Open the playground

Integration recipes

Copy a server-side Identity check and fail-closed Policy request pattern. Service credentials stay on your server.

View code examples

Starter templates

Download placeholder-only environment and Policy configuration templates. Generate real local credentials with the quickstart utility.

Get templates

Troubleshooting

Find common HTTP errors, readiness behavior, local PostgreSQL test setup, and next diagnostic steps.

Diagnose an issue

Sample-only · runs locally

Policy decision playground

Compare source and target clearance levels, compartments, and actions. This simulator mirrors the current kernel's default compartment and READ/WRITE rules, but it does not call a server, create a signed verdict, or replace validation against your configured policy.

Ready. No request has been sent.

Select inputs and evaluate to see a sample decision.

Integration recipes

Call Identity and Policy from a trusted server that owns the resource. Never put a Policy service token, signing key, or production bearer token in browser JavaScript, a public repository, or a downloadable template.

1. Validate the user's active Identity session

Example assumes your server has already accepted a bearer token from its caller.

const identity = await fetch(new URL('/api/auth/me', process.env.IDENTITY_URL), {
  headers: { Authorization: `Bearer ${userAccessToken}` },
  signal: AbortSignal.timeout(3000),
});
if (identity.status === 401 || identity.status === 403) return respond(401);
if (!identity.ok) return respond(503);
const { user } = await identity.json();

2. Ask Policy from the server, then enforce its decision

Only after Identity verification, send the verified subject and server-selected target. Fail closed on any unavailable, malformed, or denied response.

const decision = await fetch(new URL('/api/v1/governance/evaluate', process.env.POLICY_URL), {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.AARCHON_POLICY_TOKEN}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    requestId: crypto.randomUUID(),
    subjectId: user.id,
    subjectRole: user.role,
    targetDomainId: 'report-team-a',
    action: 'READ',
    payloadHash: createHash('sha256').update('/api/reports/team-a').digest('hex'),
  }),
  signal: AbortSignal.timeout(3000),
});
if (!decision.ok) return respond(503);
const verdict = await decision.json();
if (typeof verdict.allowed !== 'boolean') return respond(503);
if (!verdict.allowed) return respond(403);
return respond(200, protectedResource);

These are integration patterns, not a hosted test console. Configure service URLs, role-to-domain mappings, and credentials on your own server. See the runnable local example for a complete tested flow.

Downloadable starter templates

Files contain placeholders only. Do not deploy them unchanged. For real random credentials and protected local files, use node examples/internal-api/setup-local-policy.js from the repository root.

What the templates include

  • Example clearance domains and a role-to-domain map.
  • Placeholder database URLs, service URLs, JWT secret, signing keys, and Policy token.
  • Page guidance for generating and protecting replacement values.

The sample Policy token hash is deliberately a non-secret placeholder; replace it with the SHA-256 digest of a separately generated service token before starting Policy.

Troubleshooting and diagnostics

SignalLikely meaningNext check
GET /api/health → 200Identity process is live; this does not prove the database is ready.Check readiness separately.
GET /api/ready → 503Identity cannot reach or verify its persistence layer.Check database availability and the server-managed DATABASE_URL; never paste credentials into a support request.
401 UnauthorizedMissing, invalid, expired, or revoked user session/service token.Re-authenticate the user or verify the server's service credential and Identity response.
403 ForbiddenCross-site write rejected, administrator role absent, or Policy denied access.Inspect request origin, server-verified role mapping, compartment, and returned rule name.
400 / 415Malformed fields, unknown domain/action, or unsupported content type.Compare request JSON with the API reference; send JSON for Policy.
409 ConflictAccount email is already registered.Use the login flow; do not retry registration with altered casing.
429 Too Many RequestsAuthentication or Policy rate limit reached.Honor Retry-After where present and reduce retry frequency.
PostgreSQL tests skippedThe integration suite requires an explicitly set TEST_DATABASE_URL.Use the disposable database setup in the quickstart; tests intentionally do not fall back to production DATABASE_URL.

For system boundaries and fail-closed responsibilities, review Trust boundaries. For startup and end-to-end checks, follow the Quickstart.