autogen_stedi/lib.rs
1//! # autogen-stedi
2//!
3//! Auto-generated, strongly-typed, async Rust client for the
4//! [Stedi APIs](https://www.stedi.com/docs).
5//!
6//! Every request/response type and API method is generated directly from Stedi's public
7//! [OpenAPI specs](https://github.com/Stedi/openapi) with
8//! [openapi-generator](https://openapi-generator.tech/), so the surface stays faithful to the
9//! APIs and updates automatically when a spec changes. A thin hand-written [`StediClient`] adds
10//! API-key authentication and hands you a per-service
11//! [`Configuration`](crate::client::StediClient) with the correct base URL already set.
12//!
13//! ## Why one module per service?
14//!
15//! Stedi publishes **several independent APIs**, each with its own base URL
16//! (`claims.us.stedi.com`, `healthcare.us.stedi.com`, …) and its own spec. Each is vendored into
17//! its own top-level module — [`claims`], [`core`], [`enrollment`], [`event_destinations`],
18//! [`healthcare`], [`manager`], [`payers`] — so their (otherwise colliding) model names stay
19//! isolated. Every service is a Cargo feature: enabling only what you use skips compiling the rest
20//! entirely, models included.
21//!
22//! ## Quick start
23//!
24//! ```no_run
25//! use autogen_stedi::StediClient;
26//!
27//! # #[cfg(feature = "healthcare")]
28//! #[tokio::main]
29//! async fn main() -> Result<(), Box<dyn std::error::Error>> {
30//! let client = StediClient::new("your-api-key");
31//!
32//! // `client.healthcare()` returns a `Configuration` pointed at the Healthcare API,
33//! // ready to pass to any function in `autogen_stedi::healthcare::apis`.
34//! let _config = client.healthcare();
35//! Ok(())
36//! }
37//! # #[cfg(not(feature = "healthcare"))]
38//! # fn main() {}
39//! ```
40//!
41//! ## Authentication
42//!
43//! All Stedi APIs authenticate with an API key sent in the `Authorization` header as
44//! `Key <api-key>`. [`StediClient`] wires this up for every service:
45//!
46//! ```no_run
47//! use autogen_stedi::StediClient;
48//!
49//! let client = StediClient::new("your-api-key");
50//! ```
51//!
52//! Each `client.<service>()` accessor returns the generated `Configuration` for that service. The
53//! base URL (including the dated API version, e.g. `/2024-04-01`) is baked in from the spec; you can
54//! still override `base_path` on the returned value to point at a proxy or mock server.
55//!
56//! ## Error handling
57//!
58//! Calls return `Result<T, apis::Error<E>>`, where `E` is the endpoint-specific error enum.
59//! Each service module exposes its own `apis::Error`, which separates transport errors,
60//! (de)serialization errors, and structured API error responses (carrying the HTTP status and body).
61//!
62//! ## Feature flags
63//!
64//! By default all services are enabled. To reduce compile time, select only what you need
65//! (and a TLS backend — `native-tls` or `rustls`):
66//!
67//! ```toml
68//! [dependencies]
69//! autogen-stedi = { version = "0.1", default-features = false, features = ["healthcare", "native-tls"] }
70//! ```
71
72#![allow(unused_imports)]
73#![allow(clippy::too_many_arguments)]
74
75#[cfg(feature = "claims")]
76pub mod claims;
77#[cfg(feature = "core")]
78pub mod core;
79#[cfg(feature = "enrollment")]
80pub mod enrollment;
81#[cfg(feature = "event-destinations")]
82pub mod event_destinations;
83#[cfg(feature = "healthcare")]
84pub mod healthcare;
85#[cfg(feature = "manager")]
86pub mod manager;
87#[cfg(feature = "payers")]
88pub mod payers;
89
90pub mod client;
91
92pub use client::StediClient;