API Terms of Use

Version 2.9 · Last updated 2026-08-10 · supersedes v2.8 (2026-07-28)
Effective: upon any use of the API.

Operator: TUARA KURI LIMITED
Trading as: AgenticRail
Email: hello@agenticrail.nz

These API Terms govern access to and use of the AgenticRail API. They apply in addition to the AgenticRail Terms of Service and Privacy Policy. Capitalised terms not defined here have the meanings given in the main Terms of Service.

1. Purpose of the API

The AgenticRail API provides a deterministic execution gate that:

validates incoming actions
enforces sequence order
applies policy constraints
returns ALLOW or DENY enforcement decisions, or refuses the request with HALT

The API does not generate actions or guarantee outcomes.

2. API Keys & Account

Access to the API requires a valid API key.

You are responsible for all activity under your key.
Do not share, expose, or embed keys in public code (e.g., client-side JavaScript, mobile apps).
You must promptly notify us if your key is compromised.

AgenticRail may rotate keys, revoke keys, or limit or suspend access at any time to protect system integrity.

3. Request Contract (Required Payload)

All API requests must follow the documented structure.

Minimum required payload:

{
  "schema_version": "1.0",
  "model_id": "MSMD",
  "sequence_id": "string",
  "step": "string",
  "function": "string",
  "action_type": "string",
  "nonce": "string",
  "ts_ms": 0,
  "action": "string",
  "inputs": {}
}

Required rules:

step MUST equal function
nonce MUST be unique per request (UUID or equivalent recommended)
action_type MUST be allowed for the given step/function
sequence_id MUST be consistent within a sequence

Requests that do not meet this contract will be rejected.

4. Deterministic Enforcement

The API enforces:

strict ordered sequence (8-step spine)
function validation
action-type allowlists
nonce replay protection
sequence sealing after completion

Violations result in DENY — an enforcement decision, written to a signed Receipt — or HALT, a refusal at the boundary before enforcement runs, which produces no Receipt, or structured error responses.

The API is designed to fail closed, not fail open.

5. Sequence Rules

Steps must follow the defined order.
Steps cannot be skipped, repeated, or reordered.
Each sequence must use fresh nonces.
Once a sequence reaches the final state (settle), it is sealed.

After sealing, further requests on that sequence will be rejected.

6. Response Model

Responses include:

decision: ALLOW or DENY. A HALT carries status rather than decision, and produces no Receipt
reasons: array of reason codes
meta: validation metadata (step, action_type, etc.)

An ALLOW decision means the action passed current policy constraints. It does not mean the action is correct, the action is safe, or the action should be executed without human review.

7. Error Handling & Reason Codes

Clients must handle errors correctly.

Code	Meaning
`DENY`	Action not permitted by policy
`REPLAY_NONCE`	Nonce already used for this sequence
`SEQUENCE_VIOLATION`	Step order incorrect (skip or repeat)
`SEALED_SEQUENCE`	Sequence already completed (settle)
`ACTION_NOT_ALLOWED`	`action_type` not valid for the current function/step
`STALE_TIMESTAMP`	`ts_ms` is more than 300 seconds from server time

Clients must not assume retries will succeed without correcting the underlying issue.

8. HTTP Status Codes

The API may use standard HTTP status codes, including:

200 — Request processed successfully (ALLOW or DENY decision returned)
400 — Invalid request structure
401 / 403 — Authentication or API key issues
429 — Rate limit exceeded
500 — Internal server error

Clients must not rely solely on HTTP status codes and should always inspect the response body.

9. Rate Limits & Usage

The public demo key is rate-limited to 300 requests per minute per IP address, enforced by a single-threaded Durable Object per rate-limit key — no race conditions.

Production API access is arranged directly with the Operator (see Onboarding, below). The applicable rate limit is agreed as part of that arrangement and enforced per API key by the same Durable-Object mechanism.

There is no published self-serve pricing tier or monthly request quota. Access, rate limits, and pricing for production use are configured directly with each Client based on their use case.

Exceeding the applicable rate limit may result in throttling (HTTP 429), temporary denial, or suspension of access.

We may change rate limits with reasonable notice. The AgenticRail website (agenticrail.nz) is the authoritative source for current pricing.

Onboarding: Production API access is arranged directly with the Operator. We work with each Client to understand their use case and configure their enforcement policies before a production key is issued. The public demo key remains available immediately, at no charge, for evaluation. To arrange production access, contact hello@agenticrail.nz.

10. Idempotency and Retries

Requests are not idempotent by default.

Reusing a nonce will result in REPLAY_NONCE errors.
Each request must use a new nonce.

Clients must generate unique nonces per request, design retry logic carefully, and avoid blind retries.

11. Client Responsibilities

Clients must:

validate all API responses before execution
implement fallback or safe failure behaviour
ensure compliance with applicable laws (including the EU AI Act)
ensure safe use in their domain

AgenticRail is a control layer, not a decision engine.

AgenticRail must not be used as the sole control mechanism in any system where a DENY decision or a HALT refusal could result in harm, financial loss, or regulatory impact. The Client must implement appropriate fallback behaviour.

The Client is responsible for ensuring their configuration — including step order, function names, and action types — is correct. Unexpected DENY decisions resulting from misconfiguration are not a defect in the System.

12. Prohibited Use

You must not:

attempt to bypass sequence enforcement
send malformed or adversarial payloads to break the system
reverse engineer API behaviour
use the API to build competing enforcement systems
conduct unauthorised stress testing

Violation may result in immediate suspension.

13. Security

You must:

protect API keys
rotate keys if compromised
use secure transport (HTTPS only)
avoid submitting personal or sensitive data unless appropriate safeguards and legal basis are in place

AgenticRail is not a secure data storage system.

14. Availability & Changes

The API is provided "as is" and "as available."

We do not guarantee uptime or response times, but we use reasonable efforts to maintain availability.

The API may evolve over time, including new validation rules and updated payload requirements. Backward compatibility is not guaranteed. Breaking changes will be notified at least 30 days in advance.

15. API Versioning

Versioning is indicated via the schema_version field.
Clients are responsible for maintaining compatibility.
Deprecated versions may be removed with reasonable notice.

16. Suspension & Termination

We may suspend or terminate API access immediately if you breach these API Terms or the main Terms, your use poses a security risk, your use disrupts the API for others, or you fail to pay outstanding fees within 15 days of notice.

Upon termination, API keys will be revoked and outstanding fees become immediately due.

17. Limitation of Liability

These API Terms are subject to the Limitation of Liability clause in the main Terms of Service.

In summary: liability is capped at fees paid in the previous 12 months or NZ$100 (whichever is greater); no liability for indirect or consequential damages.

Use of the API is at your own risk.

18. Governing Law

These API Terms are governed by the laws of New Zealand. Disputes shall be resolved in the courts of New Zealand.

19. Governing Principle

The API enforces structure, not truth.
It decides what is allowed.
It does not decide what is correct.

20. Contact

For API access, key management, or questions: hello@agenticrail.nz

By using the AgenticRail API, you acknowledge that you have read, understood, and agree to be bound by these API Terms of Use, together with the Terms of Service and Privacy Policy.

Version & Change Log — v2.9

Version: 2.9 · Effective date: 2026-08-10 · Operator: TUARA KURI LIMITED · Supersedes v2.8 (2026-07-28) · prior v2.7 (2026-07-08)

v2.9 (2026-08-10): removes the registered street address from the operator block. It was a contact detail, not an address for service: notices are given by email to hello@agenticrail.nz, and the registered address of TUARA KURI LIMITED remains publicly available from the New Zealand Companies Register. No other change.

v2.8 (2026-07-28): corrects the response model and reason-code table. The decision field carries ALLOW or DENY only; a HALT is returned as status and produces no Receipt, because the request was refused before enforcement ran. Removes the HALT row from the reason-code table: HALT is not a reason code, and the behaviour that row described is a DENY (SEQUENCE_VIOLATION), which is receipted. Sections 1, 5 and 12 corrected to match.

v2.7 (2026-07-08): removes the tiered (Free/Growth/Scale/Enterprise) monthly request-quota table from Section 9 — those quota figures were never enforced anywhere in the deployed system and no self-serve pricing tier exists. Replaced with an accurate description: demo key rate limit (300 req/min per IP, enforced today) and production rate limits agreed directly per Client. No other change;.