Skip to main content
Every SDK method accepts an optional options argument that controls per-call timeouts and one-off headers. The same RequestOptions shape works for regular requests and for Server-Sent Events streams.

RequestOptions

RequestOptions is a Sendable struct with two optional fields:

Override timeout per call

Use timeout to set a shorter or longer bound for a single request.
Client.swift
The client-wide default is 30 seconds. See Client configuration for setting the default.

Inject one-off headers

Use headers to add request correlation IDs, feature flags, or override a default value once.
Client.swift

Combining options

Pass both fields together when needed:
Client.swift

Header merge order

The SDK builds the final header set in this order. Each step can overwrite the previous one:
  1. Client default headers (headers passed to the initializer)
  2. accept: application/json (regular requests) or accept: text/event-stream (streams)
  3. Per-call options.headers
  4. Authentication header (Authorization or x-api-key) from FigraniumAuthentication

Timeout and cancellation semantics

Swift concurrency uses structured cancellation. When a request exceeds the configured timeout, or when the calling Task is cancelled, the SDK raises FigraniumError with code: "REQUEST_ABORTED".
  • When a request exceeds the configured timeout, the SDK raises FigraniumError(code: "REQUEST_ABORTED").
  • When the request cannot reach the server (DNS failure, connection refused, TLS error), the SDK raises FigraniumError(code: "NETWORK_ERROR").
  • When the consuming Task is cancelled, the SDK catches the CancellationError and raises FigraniumError(code: "REQUEST_ABORTED").
Client.swift

Stream timeouts

Streams have no default timeout. Pass options: .init(timeout: 60) when you want a terminal deadline. The stream raises FigraniumError(code: "REQUEST_ABORTED") when the timer fires.
Client.swift
See Streaming for more on consuming SSE events.
Use timeout for hard deadlines on individual requests. For long-running streams, prefer cancelling the consuming Task so you can stop cleanly when your application state changes.
See Errors for the full error shape.