Skip to content

FetchFragmentsOptions

Defined in: fragments.ts:136

apiBase: string

Defined in: fragments.ts:138


optional apiBaseProvenance?: "key" | "explicit"

Defined in: fragments.ts:158

Where apiBase came from. The SDK cannot verify a key’s signature (it holds no secret), so a key-derived apiBase is still an unproven host client-side: it earns content fetches but NOT the mint POST (which carries the signed mint token and the declared dims) unless the host is first-party or loopback (S-2). Defaults to “explicit”: a caller passing apiBase directly has chosen it themselves.


optional context?: DeclaredContext

Defined in: fragments.ts:139


optional fetchImpl?: (input, init?) => Promise<Response>

Defined in: fragments.ts:160

Test seam; defaults to the platform fetch.

MDN Reference

URL | RequestInfo

RequestInit

Promise<Response>


fields: Record<string, FragmentFieldSpec>

Defined in: fragments.ts:140


optional mintToken?: MintTokenSource

Defined in: fragments.ts:144

Sent on the mint POST only — never on the GET, which is a shared CDN object and must be byte-identical for every caller. Optional: without it the mint goes unsigned and the server admits it or not.


optional onMintStarted?: () => void

Defined in: fragments.ts:165

Called once when the server has accepted a request-time generation and is writing the copy for this very page view. A renderer holding the canvas may restart its budget ONCE here — the same rule as an island stream proving it is alive (copyStart).

void


organizationId: string

Defined in: fragments.ts:137


optional publishableKey?: string

Defined in: fragments.ts:151

st_pk_… from the dashboard. Sent on the mint POST only, as Authorization: Bearer <key> — never on the GET, for the same reason as the token. A live key sent from an origin registered to the org is enough for the server to admit the mint, so a site with no backend (a brand page) gets live copy. When mintToken is also given, both are sent and the server prefers the token.