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.
 *
 * @remarks
 * Intersected with `HTMLElement` because the controller dispatches events on the host. Lit's `ReactiveControllerHost` is the update-lifecycle contract only (`addController`, `requestUpdate`, `updateComplete`) and carries no DOM surface, even though every real host is a `LitElement` and therefore an `HTMLElement`. Declaring the DOM half is what the controller actually needs; it used to reach it through a `this.host as unknown as EventTarget` double cast instead, which asserted a capability the type never promised.
 */
type FetchHost<T> = ReactiveControllerHost & HTMLElement & {
    data: T | null;
    loading: boolean;
    error: string | null;
};
/** Default RoxyAPI v2 origin. A component overrides it per instance via its `base-url` attribute. */
/** The public API root. Exported so anything else that must reach the API (the field-label
 * fetch in `endpoint-form`) uses the SAME origin as every data request instead of a second copy. */
export declare const DEFAULT_BASE_URL = "https://roxyapi.com/api/v2";
/**
 * Turn a failed `Response` into the message to show: the API's own `{ error }` string when the body carries one, else the status line.
 *
 * @remarks
 * Exported so every client-side fetch boundary renders the same words for the same failure, the way {@link keyIsRefused} centralizes the key refusal. A boundary that discards the response body cannot tell a rejected request from an empty result, and renders the two identically.
 */
export declare function readApiError(res: Response): Promise<string>;
/** 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;
    /**
     * Object the host page attaches to the proxied request, carried beside it as `context`. Set by the host from its `submit-context` attribute, and shapeless on purpose: this passes it through and reads no key of it, so what it holds is for the page and its own route to agree on.
     *
     * @remarks
     * Only the {@link FetchController.submitUrl} path can carry it, because that is the only body this code writes. A direct call sends the request the endpoint declares and nothing beside it.
     */
    submitContext?: Record<string, unknown>;
    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>;
    /**
     * The body of a proxied POST: the request, plus {@link FetchController.submitContext} under `context` when the host set one.
     *
     * @remarks
     * The context is appended rather than declared on {@link RoxyRequest}, so with none set the payload is the request object itself and every route already written against it keeps receiving the same four keys in the same order. A `null` or an empty object would be a fifth key such a route never agreed to read.
     */
    private proxyBody;
    /** 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, via the shared {@link keyIsRefused} guard so every fetch boundary fail-closes identically. */
    private secretKeyRefused;
}
/**
 * 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.
 *
 * @param queryKeys - Names the spec declares as `in: query` for this operation, which `<roxy-endpoint-form>` reports on its `roxy-submit` event. A POST operation can still take query parameters (every localized endpoint takes `?lang=`), and sending one in the JSON body silently drops it, so those names are routed to the query string on POST as well as GET.
 */
export declare function buildRequest(endpoint: string, method: 'GET' | 'POST', values: Record<string, unknown>, queryKeys?: readonly string[]): RoxyRequest;
export {};
//# sourceMappingURL=fetch-controller.d.ts.map