@weftlabs/sdk 0.25.0

package/dist/facilitator/middleware/index.d.ts

@@ -0,0 +1,539 @@
+import { OutgoingHttpHeaders } from 'node:http';
+import { RouteConfig, RoutesConfig, HTTPRequestContext, CompletedSettlement, PaymentCancellationDispatcher, PaywallConfig, PaywallProvider, x402ResourceServer } from '@x402/core/server';
+export { PaywallConfig, PaywallProvider, RouteConfig, RoutesConfig } from '@x402/core/server';
+import { PaymentPayload, PaymentRequirements, Network, SchemeNetworkServer } from '@x402/core/types';
+export { Network, SchemeNetworkServer } from '@x402/core/types';
+import { W as WeftFacilitatorConfig } from '../../client-C9_zh3Qg.js';
+
+/**
+ * What kind of thing the seller is selling.
+ *
+ * Deliberately small. If you need a kind that is not here, use `tags`.
+ */
+type WeftProductType = "api" | "agent" | "mcp";
+/**
+ * Reserved tag prefix that carries {@link WeftProductIdentity.type} on the wire.
+ *
+ * `ResourceInfo` in the x402 protocol has no field for a product kind, and the
+ * facilitator only relays `serviceName`, `tags` and `iconUrl` to the settlement
+ * event. `tags` is therefore the only channel a product type can travel in, so
+ * the SDK encodes it as one reserved tag — `weft:type:api`, `weft:type:agent`,
+ * `weft:type:mcp`.
+ *
+ * The prefix is namespaced so it cannot collide with a seller's own free-text
+ * tags, stays readable in a raw settlement row, and is matched downstream with
+ * a plain `startsWith`. The SDK guarantees at most one such tag per route: any
+ * `weft:type:*` value a caller puts in `tags` is dropped with a warning, in
+ * favour of the `type` field on the product or on the route.
+ */
+declare const WEFT_TYPE_TAG_PREFIX = "weft:type:";
+/**
+ * Product-level identity, declared once and applied to every protected route.
+ *
+ * This is what turns a settlement into a named product in the Weft dashboard.
+ * Every field is optional; a middleware configured without any of them behaves
+ * exactly as it did before this identity existed.
+ *
+ * Every field is also validated at construction time, because these values
+ * routinely come from JSON or env and TypeScript is not present at runtime.
+ * Anything the x402 protocol cannot carry is clamped or dropped, with one
+ * `[weft]` line explaining what shipped — never a thrown error in a payment
+ * server's boot path, and never a malformed challenge on the wire.
+ */
+interface WeftProductIdentity {
+    /**
+     * Display name of the product, e.g. `"Acme Pricing API"`.
+     *
+     * Travels as `ResourceInfo.serviceName` on the 402 challenge. The protocol
+     * carries 32 printable-ASCII characters; a longer name is truncated to fit,
+     * with a warning naming both values.
+     */
+    name?: string;
+    /**
+     * What kind of product this is.
+     *
+     * Travels as a reserved `weft:type:<type>` tag — see {@link WEFT_TYPE_TAG_PREFIX}.
+     * A route may declare its own `type`, which wins for that route.
+     */
+    type?: WeftProductType;
+    /**
+     * Free-text tags describing the product, e.g. `["finance", "pricing"]`.
+     *
+     * Travels as `ResourceInfo.tags`. Tags starting with `weft:type:` are
+     * reserved and are dropped in favour of {@link WeftProductIdentity.type}.
+     *
+     * The x402 protocol allows five tags of at most 32 printable-ASCII
+     * characters. A declared `type` uses one slot, so four remain. Anything
+     * beyond that is dropped with a warning rather than being put on the wire,
+     * because an out-of-bounds array costs the seller every tag they declared.
+     */
+    tags?: string[];
+    /**
+     * Absolute `http:` or `https:` URL of an icon for the product.
+     *
+     * Travels as `ResourceInfo.iconUrl`. A dashboard renders this URL, so any
+     * other scheme is dropped with a warning.
+     */
+    iconUrl?: string;
+}
+/**
+ * Extension key under which the product declaration travels on the wire.
+ *
+ * Unlike the identity fields, which ride `ResourceInfo`, the product
+ * declaration rides x402 v2 `extensions`: declared by the server on the 402
+ * challenge, echoed by the buyer's client onto `PaymentPayload`, validated
+ * against the advertisement at verify time, and relayed by the facilitator on
+ * the settlement event.
+ */
+declare const WEFT_PRODUCT_EXTENSION_KEY = "weft.product";
+/**
+ * JSON Schema (Draft 2020-12) for the `weft.product` extension's `info`.
+ *
+ * Ships verbatim as the extension's `schema` member, per the x402 v2
+ * extensions shape `{info, schema}`. Every field is optional because absent
+ * declarations are omitted from `info` rather than sent empty.
+ *
+ * `additionalProperties: false` is a **published contract statement, not an
+ * enforcement**. Upstream's echo check is a subset match — advertised `info`
+ * fields must be preserved, but a buyer may *add* fields to the echoed
+ * `info` and pass, and when a route advertises no extensions the check never
+ * runs. So an echoed `weft.product` proves nothing about fields the seller
+ * did not advertise: by the time it reaches a consumer it is unauthenticated
+ * buyer input. A buyer has no legitimate reason to add fields to a seller
+ * claim, and this flag is the declared basis for consumers to strip
+ * anything unadvertised — but the stripping, and the deeper rule, are the
+ * consumer's job. Attribution must never key on echoed extension contents;
+ * it keys on seller-authenticated joins — the API key that settled the
+ * payment (weft-app #635 freezes `payments.product_id` from exactly that at
+ * settlement time) or the S1 handshake's authenticated declaration.
+ */
+declare const WEFT_PRODUCT_INFO_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly type: "object";
+    readonly properties: {
+        readonly kind: {
+            readonly type: "string";
+            readonly enum: readonly string[];
+        };
+        readonly product_id: {
+            readonly type: "string";
+            readonly minLength: 1;
+        };
+        readonly manifest_hash: {
+            readonly type: "string";
+            readonly minLength: 1;
+        };
+    };
+    readonly additionalProperties: false;
+};
+/**
+ * Product-level declaration: the identity plus the product reference fields.
+ *
+ * `productId` and `manifestHash` are not cosmetic identity — they are the
+ * seller's claim about *which* dashboard product this deployment is and what
+ * manifest it was built from. They travel in the `weft.product` extension,
+ * never in `ResourceInfo`, so they extend the identity type rather than
+ * joining it.
+ */
+interface WeftProductDeclaration extends WeftProductIdentity {
+    /**
+     * Identifier of the dashboard product this deployment claims to be.
+     *
+     * Travels as `extensions["weft.product"].info.product_id` on the 402
+     * challenge and, echoed by the buyer, on the payment payload the
+     * facilitator settles.
+     */
+    productId?: string;
+    /**
+     * Hash of the product manifest this deployment was built from.
+     *
+     * Travels as `extensions["weft.product"].info.manifest_hash`, next to
+     * {@link WeftProductDeclaration.productId}. Opaque to the SDK: no format is
+     * enforced beyond being a non-empty string.
+     */
+    manifestHash?: string;
+    /**
+     * Field names inside `weft.request` that revenue may be broken down by,
+     * e.g. `["model", "tier"]`.
+     *
+     * Travels only on the authenticated boot handshake — never on the 402
+     * challenge, never in `weft.product`. That is the point of it: the values
+     * on a payment are buyer-echoed, so an aggregate summing an *undeclared*
+     * key would be summing buyer-controlled input. A field declared here is
+     * one the seller vouched for under their own API key, which is what makes
+     * "revenue for model=gpt-5.6 this month" an answer rather than a guess.
+     *
+     * Declare dimensions, not payloads. Low cardinality, enumerable: `model`,
+     * `tier`, `size`, `region`. Never prompt text, a user id or a document
+     * body — those blow up the index, leak content, and are useless as a
+     * breakdown anyway.
+     */
+    dimensions?: string[];
+}
+/**
+ * A route config that may also declare the product kind for that route alone.
+ *
+ * `RouteConfig` comes from `@x402/core` and has no field for a product kind.
+ * A seller whose surface is part API and part MCP needs to say so per route,
+ * so the SDK accepts `type` here, consumes it into the reserved tag, and never
+ * passes the field itself down to the resource server.
+ *
+ * The inherited `extensions` map gains one capability here: any value may be a
+ * `WeftDynamicExtension` callback instead of a static object, resolved per
+ * request at the same point as `price`. The field is already typed
+ * `Record<string, unknown>` upstream, so this needs no wider type — only the
+ * middleware registering the resolver for those keys.
+ */
+interface WeftRouteConfig extends RouteConfig {
+    /** Product kind for this route; overrides {@link WeftProductIdentity.type}. */
+    type?: WeftProductType;
+}
+/** {@link RoutesConfig}, with per-route {@link WeftRouteConfig.type} allowed. */
+type WeftRoutesConfig = Record<string, WeftRouteConfig> | WeftRouteConfig;
+/**
+ * Build the reserved tag for a product type.
+ *
+ * @param type - The product type to encode
+ * @returns The reserved tag, e.g. `weft:type:api`
+ */
+declare function productTypeTag(type: WeftProductType): string;
+/**
+ * Merge product-level identity into every protected route.
+ *
+ * A per-route value always wins over the product-level default, so a seller
+ * who names one route individually keeps that name. Fields nobody declared
+ * stay absent from the 402 challenge rather than being sent empty.
+ *
+ * Every value this produces is inside the bounds `ResourceInfoSchema` declares,
+ * so the challenge the middleware emits parses for any buyer that validates.
+ * Values that cannot be made to fit are clamped or dropped, each with one
+ * `[weft]` line at construction time.
+ *
+ * A config that declares no Weft identity at all — neither on the middleware
+ * nor on a route — is returned by reference, exactly as the caller wrote it.
+ * That is the pre-identity behaviour, kept deliberately: with nothing of ours
+ * on the routes, what the seller puts in a `RouteConfig` is between them and
+ * `@x402/core`.
+ *
+ * @param routes - Route configuration passed by the caller
+ * @param identity - Product-level declaration from the middleware config
+ * @returns Route configuration with identity applied; the input is never mutated
+ */
+declare function applyProductIdentity(routes: WeftRoutesConfig, identity: WeftProductDeclaration): RoutesConfig;
+
+/** A structurally valid, but not cryptographically verified, v2 payment. */
+interface PaymentResumeCandidate {
+    paymentPayload: PaymentPayload;
+    paymentRequirements: PaymentRequirements;
+}
+/** Verified payment inputs restored from durable application storage. */
+interface VerifiedPaymentResume {
+    paymentPayload: PaymentPayload;
+    paymentRequirements: PaymentRequirements;
+    declaredExtensions?: Record<string, unknown>;
+    /** Restore this receipt when Core settled before the original handler. */
+    beforeHandlerSettlement?: CompletedSettlement;
+    /** Restore Core's cancellation state for a before-handler settlement. */
+    cancellationDispatcher?: PaymentCancellationDispatcher;
+}
+/**
+ * Restore a previously verified payment for settlement replay.
+ *
+ * This callback is a trust boundary. The caller must durably bind its result to
+ * the exact signed payment payload and request fingerprint. The SDK does not
+ * authenticate or validate callback output before settlement.
+ */
+type ResumeVerifiedPayment = (context: HTTPRequestContext, candidate: PaymentResumeCandidate) => VerifiedPaymentResume | undefined | Promise<VerifiedPaymentResume | undefined>;
+
+interface ExpressRequest {
+    method: string;
+    path: string;
+    protocol: string;
+    headers: Record<string, string | string[] | undefined>;
+    query: Record<string, string | string[] | undefined>;
+    body?: unknown;
+    header(name: string): string | string[] | undefined;
+}
+interface ExpressResponse {
+    status(code: number): ExpressResponse;
+    setHeader(name: string, value: string | number | readonly string[]): ExpressResponse;
+    /**
+     * Headers the route handler has set. Read at settlement time so a
+     * `Settlement-Overrides` header reaches the facilitator.
+     */
+    getHeaders(): OutgoingHttpHeaders;
+    removeHeader(name: string): void;
+    send(body: unknown): ExpressResponse;
+    json(body: unknown): ExpressResponse;
+    statusCode: number;
+    writeHead: (...args: unknown[]) => ExpressResponse;
+    write: (...args: unknown[]) => boolean;
+    end: (...args: unknown[]) => ExpressResponse;
+    flushHeaders: () => void;
+}
+type ExpressNextFunction = (err?: unknown) => void;
+type ExpressMiddleware = (req: ExpressRequest, res: ExpressResponse, next: ExpressNextFunction) => Promise<void> | void;
+interface SchemeRegistration$1 {
+    network: Network;
+    server: SchemeNetworkServer;
+}
+/**
+ * Configuration for the Express payment middleware.
+ *
+ * Extends {@link WeftProductDeclaration}, so `name`, `type`, `tags`,
+ * `iconUrl`, `productId` and `manifestHash` are declared once here and
+ * applied to every protected route.
+ */
+interface WeftExpressMiddlewareConfig extends WeftProductDeclaration {
+    /**
+     * The seller's Weft API key.
+     *
+     * Authenticates the facilitator calls that need it: `X-API-Key` on
+     * `/settle` — which the facilitator requires, or every settlement 401s —
+     * and `Authorization: Bearer <key>` on the construction-time `/supported`
+     * handshake, which is how the dashboard learns an SDK is deployed before
+     * any payment. Optional, but a seller who omits it must supply their own
+     * `facilitator.createAuthHeaders` or settlement fails.
+     */
+    apiKey?: string;
+    facilitator?: WeftFacilitatorConfig;
+    schemes?: SchemeRegistration$1[];
+    paywallConfig?: PaywallConfig;
+    paywall?: PaywallProvider;
+    syncFacilitatorOnStart?: boolean;
+    /** Restore durably bound verified inputs for settlement replay. */
+    resumeVerifiedPayment?: ResumeVerifiedPayment;
+}
+/**
+ * Create an Express middleware that requires x402 payment for the given routes.
+ *
+ * Product identity declared on `config` (`name`, `type`, `tags`, `iconUrl`) is
+ * merged into every route, so it travels on the 402 challenge's `resource` and
+ * from there onto the buyer's payment payload and the settlement event.
+ *
+ * @param routes - Route configuration, either a path map or a single route;
+ *   each route may declare its own `type` to override the product's
+ * @param config - Facilitator, scheme, paywall and product identity settings
+ * @returns An Express middleware function
+ */
+declare function weftPaymentMiddleware(routes: WeftRoutesConfig, config?: WeftExpressMiddlewareConfig): ExpressMiddleware;
+
+interface HonoRequest {
+    method: string;
+    path: string;
+    url: string;
+    header(name: string): string | undefined;
+    query(): Record<string, string>;
+    query(name: string): string | undefined;
+    json(): Promise<unknown>;
+}
+interface HonoContext {
+    req: HonoRequest;
+    res: Response | undefined;
+    error?: Error;
+    header(name: string, value: string | undefined, options?: {
+        append?: boolean;
+    }): void;
+    html(body: string, status?: number): Response;
+    json(body: unknown, status?: number): Response;
+}
+type HonoMiddleware = (c: HonoContext, next: () => Promise<void>) => Promise<Response | void>;
+interface SchemeRegistration {
+    network: Network;
+    server: SchemeNetworkServer;
+}
+/**
+ * Configuration for the Hono payment middleware.
+ *
+ * Extends {@link WeftProductDeclaration}, so `name`, `type`, `tags`,
+ * `iconUrl`, `productId` and `manifestHash` are declared once here and
+ * applied to every protected route.
+ */
+interface WeftHonoMiddlewareConfig extends WeftProductDeclaration {
+    /**
+     * The seller's Weft API key.
+     *
+     * Authenticates the facilitator calls that need it: `X-API-Key` on
+     * `/settle` — which the facilitator requires, or every settlement 401s —
+     * and `Authorization: Bearer <key>` on the construction-time `/supported`
+     * handshake, which is how the dashboard learns an SDK is deployed before
+     * any payment. Optional, but a seller who omits it must supply their own
+     * `facilitator.createAuthHeaders` or settlement fails.
+     */
+    apiKey?: string;
+    facilitator?: WeftFacilitatorConfig;
+    schemes?: SchemeRegistration[];
+    paywallConfig?: PaywallConfig;
+    paywall?: PaywallProvider;
+    syncFacilitatorOnStart?: boolean;
+    /** Restore durably bound verified inputs for settlement replay. */
+    resumeVerifiedPayment?: ResumeVerifiedPayment;
+}
+/**
+ * Create a Hono middleware that requires x402 payment for the given routes.
+ *
+ * Product identity declared on `config` (`name`, `type`, `tags`, `iconUrl`) is
+ * merged into every route, so it travels on the 402 challenge's `resource` and
+ * from there onto the buyer's payment payload and the settlement event.
+ *
+ * @param routes - Route configuration, either a path map or a single route;
+ *   each route may declare its own `type` to override the product's
+ * @param config - Facilitator, scheme, paywall and product identity settings
+ * @returns A Hono middleware function
+ */
+declare function weftPaymentMiddlewareHono(routes: WeftRoutesConfig, config?: WeftHonoMiddlewareConfig): HonoMiddleware;
+
+/**
+ * A route extension whose value is computed per request.
+ *
+ * Declared in place of a static value under a key of a route's `extensions`,
+ * and evaluated at the same point as the `price` callback — while the 402
+ * challenge is being built, with the same {@link HTTPRequestContext}. The
+ * resolved value ships on the challenge, the buyer's client echoes it onto the
+ * payment payload, and the facilitator relays it onto the settlement event, so
+ * a seller who prices from the request body can also say what that body asked
+ * for:
+ *
+ * ```ts
+ * {
+ *   accepts: [{ scheme, network, payTo, price: quote }],
+ *   extensions: {
+ *     [WEFT_REQUEST_EXTENSION_KEY]: async (context) => {
+ *       const { model, max_tokens } = (await context.adapter.getBody()) as Body;
+ *       return { model, max_tokens };
+ *     },
+ *   },
+ * }
+ * ```
+ *
+ * {@link WEFT_REQUEST_EXTENSION_KEY} is the key to reach for. Under it the SDK
+ * owns the envelope: the callback returns the `info` payload alone and the
+ * published {@link WEFT_REQUEST_INFO_SCHEMA} is stamped beside it, exactly as
+ * `weft.product` is assembled from declared fields. Under any other key the
+ * resolved value ships verbatim, envelope and all — the escape hatch for a
+ * seller who needs their own namespace on the wire.
+ *
+ * Two rules the callback has to hold to.
+ *
+ * **It must be deterministic for one request.** The challenge is built twice —
+ * once for the unpaid request, once for the buyer's paid retry — and upstream
+ * rejects the payment with `extension_echo_mismatch` when what the buyer
+ * echoes no longer matches what the retry advertises. Derive the value from
+ * the request; never from a clock, a counter or a random source.
+ *
+ * **It is display-only.** By the time the value reaches a consumer it is
+ * unauthenticated buyer input, exactly like every other echoed extension.
+ * Attribution stays keyed on the authenticated API key that settled the
+ * payment, never on anything in here.
+ *
+ * The value travels as JSON and is advertised as JSON round-trips it, so a
+ * `NaN` arrives as `null` and a function-valued field does not arrive at all.
+ * Return plain JSON data and the question never comes up.
+ */
+type WeftDynamicExtension = (context: HTTPRequestContext) => unknown | Promise<unknown>;
+/**
+ * Extension key for the seller's per-request context.
+ *
+ * The one *named* key this mechanism ships, and the one to use unless a
+ * seller needs their own namespace on the wire. x402 extensions are named
+ * capabilities with published contracts — discovery, receipts, gas sponsoring
+ * — registered and reviewed rather than invented per seller. A key that any
+ * seller may invent is a metadata channel wearing an extension's clothes, so
+ * the SDK publishes one key with one contract and leaves the free-form form
+ * as the deliberate exception.
+ *
+ * Sits beside {@link WEFT_PRODUCT_EXTENSION_KEY}, and divides cleanly from it:
+ * `weft.product` says what is being sold and is fixed at boot; `weft.request`
+ * says what this one call asked for and is resolved per request.
+ */
+declare const WEFT_REQUEST_EXTENSION_KEY = "weft.request";
+/**
+ * JSON Schema (Draft 2020-12) for the `weft.request` extension's `info`.
+ *
+ * Ships verbatim as the extension's `schema` member. Deliberately open where
+ * `WEFT_PRODUCT_INFO_SCHEMA` is closed: what a request asked for is the
+ * seller's vocabulary — `{model, max_tokens}` for one rail, `{pages}` for
+ * another — and no schema Weft could author would fit them all.
+ *
+ * The contract it publishes is therefore not a field list but a posture: this
+ * key holds seller-authored, display-only context for one request, and a
+ * consumer must key nothing on it. `additionalProperties: true` states that
+ * openness rather than leaving it to be inferred from an absent constraint.
+ */
+declare const WEFT_REQUEST_INFO_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly title: "Weft per-request context";
+    readonly description: string;
+    readonly type: "object";
+    readonly additionalProperties: true;
+};
+/**
+ * Largest serialized extensions object, in bytes, the SDK will put on a
+ * challenge.
+ *
+ * Mirrors the facilitator's own `MAX_EXTENSIONS_BYTES` relay cap, and is
+ * measured the same way: on the whole object, key names included. The
+ * facilitator omits *every* extension when the object is over — `weft.product`
+ * with it — so a resolved value that would take the object past the cap is
+ * dropped here, on its own key, where the rest of the declaration survives.
+ *
+ * Keep these blobs small. They describe a request; they are not a place to
+ * store one.
+ */
+declare const MAX_EXTENSION_BYTES: number;
+/**
+ * Teach a resource server to resolve the routes' {@link WeftDynamicExtension}
+ * callbacks.
+ *
+ * Upstream reads `routeConfig.extensions` straight off the shared, long-lived
+ * route config, so a per-request value cannot be written there without racing
+ * every concurrent request. `registerExtension` is the path that *is* request
+ * scoped: the enrichment hook runs while the challenge for one request is
+ * being built, and its return value replaces that request's copy of the key —
+ * which is the same object the verify and settle steps go on to see.
+ *
+ * A config with no callbacks registers nothing at all.
+ *
+ * @param server - The resource server the middleware is building on
+ * @param routes - Route configuration passed by the caller
+ */
+declare function registerDynamicExtensions(server: x402ResourceServer, routes: WeftRoutesConfig): void;
+
+/**
+ * Header that carries the seller's declared product identity on the
+ * construction-time `/supported` call.
+ *
+ * The value is base64url-encoded JSON of
+ * `{name, type, tags, icon_url, dimensions}`. The first four are exactly the
+ * identity the 402 challenge will carry, so a dashboard fed from the
+ * handshake and one fed from settlements agree.
+ *
+ * `dimensions` is the exception, and travels here *only*. It never touches
+ * the challenge, because its whole job is to be the one statement about a
+ * payment's metadata that a buyer never had a chance to author: this call is
+ * authenticated by the seller's API key, so a field named here is a field the
+ * seller vouched for. That is what lets revenue be summed by it.
+ *
+ * Fields nobody declared are absent from the JSON, and the header itself is
+ * absent when nothing was declared at all.
+ */
+declare const WEFT_DECLARED_HEADER = "X-Weft-Declared";
+/** The middleware adapters a handshake can identify itself as. */
+type WeftAdapterName = "express" | "hono";
+/**
+ * Header the Weft facilitator reads the seller's API key from on `/settle`
+ * and `/verify`.
+ *
+ * The facilitator's `/settle` handler validates this header and returns 401
+ * without it, so a seller who sets `apiKey` and nothing else must have it
+ * here or every settlement — the step that credits their wallet — fails.
+ * `/verify` does not require the key, but the facilitator reads it when
+ * present and stamps the verification event with the key's digest; the SDK
+ * sends it there too so the seller's funnel attributes verification attempts
+ * instead of counting settlements against zero. `/supported` carries the same
+ * key as a bearer for the handshake, so one key travels under two header names
+ * by the facilitator's own design, not the SDK's whim.
+ */
+declare const WEFT_API_KEY_HEADER = "X-API-Key";
+
+export { type ExpressMiddleware, type HonoMiddleware, MAX_EXTENSION_BYTES, type PaymentResumeCandidate, type ResumeVerifiedPayment, type SchemeRegistration$1 as SchemeRegistration, type VerifiedPaymentResume, WEFT_API_KEY_HEADER, WEFT_DECLARED_HEADER, WEFT_PRODUCT_EXTENSION_KEY, WEFT_PRODUCT_INFO_SCHEMA, WEFT_REQUEST_EXTENSION_KEY, WEFT_REQUEST_INFO_SCHEMA, WEFT_TYPE_TAG_PREFIX, type WeftAdapterName, type WeftDynamicExtension, type WeftExpressMiddlewareConfig, type WeftHonoMiddlewareConfig, type WeftProductDeclaration, type WeftProductIdentity, type WeftProductType, type WeftRouteConfig, type WeftRoutesConfig, applyProductIdentity, productTypeTag, registerDynamicExtensions, weftPaymentMiddleware, weftPaymentMiddlewareHono };