gingr/lib.rs
1//! Gingr integration surfaces for DTO mapping, endpoints, transport, and webhook verification.
2//!
3//! # Operator framing
4//!
5//! Use this crate page to understand how raw Gingr provider facts enter the NVA
6//! system before they become trusted domain evidence. It matters to operators
7//! because reservations, pets, customers, labor, retail, and webhook events from
8//! Gingr are useful for drafting briefs or recommendations only after they pass
9//! through redacted transport, DTO quarantine, mapping, and domain promotion.
10//!
11//! The next step is to open `endpoint` for the source surface being read,
12//! `mapping` for how provider vocabulary is translated, `transport` for
13//! redacted request/response handling, or `webhook` for inbound event
14//! verification. These Rust modules document integration mechanics; they do not
15//! authorize provider writes, customer messages, schedule changes, or policy
16//! overrides.
17//!
18//! Crosswalk navigation: Gingr surfaces are source-entry evidence until a mapper
19//! or `domain::source` contract normalizes them. Use
20//! `docs/entity-atlas/contract-crosswalk/source-provider-flows.md` for the
21//! provider DTO -> mapper/source -> domain/app/storage path and the tests that
22//! prove each supported promotion or explicit provider-surface gap.
23/// Validated tenant URL, provider label, and redacted API-key configuration for Gingr requests.
24pub mod config;
25/// Raw Gingr DTO surfaces that are intentionally quarantined before NVA domain promotion.
26pub mod dto;
27pub mod endpoint;
28pub mod mapping;
29/// HTTP and provider response envelopes that retain raw Gingr evidence for later decoding.
30pub mod response;
31/// Secret-aware request capture, redaction, and transport abstractions for Gingr endpoints.
32pub mod transport;
33pub mod webhook;
34
35pub use config::{ApiKey, BaseUrl, Provider, Subdomain};