import type { ReactiveController, ReactiveControllerHost } from 'lit';
/**
 * Host slots the controller drives. {@link RoxyDataElement} satisfies this, so
 * the form mixin can attach a controller without the component wiring state by hand.
 */
interface FetchHost<T> extends ReactiveControllerHost {
    data: T | null;
    loading: boolean;
    error: string | null;
}
/** A single request the controller issues on the component's behalf. */
export interface RoxyRequest {
    /** Path under the API base, e.g. "/dreams/symbols/water" or "/astrology/natal-chart". */
    path: string;
    method?: 'GET' | 'POST';
    /** JSON body for POST endpoints. */
    body?: unknown;
    /** Query string parameters; nullish values are dropped. */
    query?: Record<string, string | number | undefined>;
}
/**
 * Client-side fetch for uncontrolled (self-fetching) components: drives `host.data` / `host.loading` / `host.error` and cancels a stale request when a newer one starts or the host disconnects.
 *
 * @remarks
 * Security boundary. The only credential this ever sends is a `pk_` publishable key, which carries a server-side origin allowlist. A secret (`sk_`) or legacy unprefixed key is refused before any network call and surfaced as an error, so a server secret cannot leak into a browser request. This centralizes the guard that originated in `<roxy-location-search>` so every self-fetching component enforces it identically.
 *
 * Controlled-mode components never construct this. When a server injects the response as a `<script class="roxy-data">` island, there is no key and no fetch, which is the path server-rendered consumers (WordPress, JSX SSR, static HTML) rely on.
 */
export declare class FetchController<T = unknown> implements ReactiveController {
    private readonly host;
    private abort?;
    /** Browser-safe publishable key. Set by the host from its `publishable-key` attribute. */
    publishableKey?: string;
    /** API origin, overridable for self-hosted or proxied deployments. */
    baseUrl: string;
    /**
     * Consumer backend route that holds the secret key. When set, the request is POSTed here as `{ path, method, body, query }` instead of called against RoxyAPI directly, so no key (publishable or secret) is sent from the browser. This is the canonical path for server-rendered hosts (WordPress); the backend proxies the request with its own `sk_` key and returns the JSON response.
     */
    submitUrl?: string;
    constructor(host: FetchHost<T>);
    hostDisconnected(): void;
    /**
     * Issue the request and resolve once `host.data` (success) or `host.error`
     * (failure) is set. A no-op return when a non-publishable key is present:
     * the error is already surfaced and nothing is sent.
     */
    run(req: RoxyRequest): Promise<void>;
    /** Direct call against RoxyAPI with the publishable key (the no-backend path). */
    private callApi;
    /** True when a key is set and it is not a browser-safe `pk_` publishable key. Surfaces the error and refuses to send. */
    private secretKeyRefused;
    /** Surface the `{ error, code }` message the API returns on failure, falling back to the status code. */
    private readError;
}
/**
 * Translate flat form values into a {@link RoxyRequest} for an endpoint. The `{name}` segments in the endpoint template are substituted from the values and removed; the rest become the JSON body for POST or query parameters for GET. This is the spec-light request builder the base element uses to turn a `<roxy-endpoint-form>` submission into a self-fetch, so a component needs no per-endpoint glue.
 */
export declare function buildRequest(endpoint: string, method: 'GET' | 'POST', values: Record<string, unknown>): RoxyRequest;
export {};
//# sourceMappingURL=fetch-controller.d.ts.map