Package-root integrations

Connect AnswerUp to your existing HTTP workflow. Your application sends the request, and a separate verifier checks the system of record. Run HTTP reference preview.4 to handle a lost response and check the original operation without sending it again. The example uses the current package set and a local test system. This page explains package-root integration boundaries.

The application is the software using AnswerUp; the host is the trusted runtime/backend environment operating the integration; the integration owner supplies and governs that integration. The supported package import boundary is the package root.

import { createProtectedActionRuntime } from '@answerup/actions';
const runtime = createProtectedActionRuntime();

Do not use deep imports, workspace paths, or guessed exports. Core uses CommonJS; Runtime and Actions use ESM. Use the exact versioned signatures in the API Reference.

Adapting existing proposal field names

Actions preview.8 reserves authority-related property names in proposal data, including tenant, even when they are ordinary fields in your existing application. Its guard also checks nested proposal objects and does not accept reserved fields merely because validateProposal removes them. This rejection returns the generic INVALID_PROPOSAL reason before dispatch. Read the "Reserved proposal fields in Actions preview.8" section in trusted context for the exact field list and adaptation guidance before wiring existing records to run. Keep trusted context separate and keep your business authorization checks when mapping to a non-reserved business field.

Example: a package-root boundary

An integrator may create a protected-action runtime from the package root and provide its own bounded provider, verifier, policy, and trusted-context dependencies. The runtime object is not a provider connection, and this excerpt does not execute the lumber reservation. Keep credentials outside result objects and use the selected declarations and your authorized package downloads.

Package-root contract

The supported public executable boundary is the package root for @answerup/core, @answerup/runtime, and @answerup/actions. Deep imports, workspace paths, guessed exports, and copied declaration files are not substitutes for that contract. The exact declaration snapshots prove API/type identity only; they do not prove package availability, semantic correctness, deployment readiness, publication, or entitlement.

The current Retell adapter preview.3 uses Actions preview.8. The Retell API page here separately documents historical preview.1 declarations; do not use those signatures for the current adapter.

What the host still supplies

Creating a Runtime or Actions object does not supply a provider, verifier, policy authority, credentials, durable action record, or HTTP transport. Durable-store interfaces in Actions describe a host-supplied persistence contract; they do not provide hosted durable storage or prove restart-safe reconciliation. The host must register or provide those boundaries according to the package contract, enforce its own input and privacy limits, and decide how results become application behavior. A package API can classify a result; it cannot know whether a host’s inventory system is authoritative unless the host connects the correct independent verifier/read-back.

Current executable example

The selected HTTP reference archive 0.2.0-preview.4 uses Core 1.0.0-rc.1, Runtime 0.2.0-preview.5 and Actions 0.2.0-preview.8. Run it from the starting instructions.

Version history and evidence

The older private application-local HTTP reference at commit 839489149ee8ed9843f80133ae1838f492bf98b4 used Core rc.1, Runtime preview.3 and Actions preview.4. It is a separate historical source reference, not that runnable archive; no newer compatibility is inferred for the older source.

Example: adapter preparation

An integrator creates the Actions runtime, supplies a trusted-context resolver, and prepares a refund operation with a separate provider and ledger verifier. The package-root import can be type-checked against frozen declarations, but nothing in the excerpt sends a refund. If the host passes a malformed context or a verifier that returns an unsupported shape, it must fail closed rather than cast the value into a success result.

Important boundaries

A Runtime handle does not survive process loss. A successful preparation does not prove dispatch, and a provider response does not prove effect truth. Package declarations establish API/type identity, not adapter certification or external effects.