๐งฉ Extending Mail Intake
Mail Intake is designed to be extended through its public contracts. Implement your own adapter, auth provider, or credential store to support a new provider or storage backend.
๐ฌ Custom adapters
Subclass MailIntakeAdapter to integrate a new provider. Adapters perform
read-only transport and return provider-native payloads:
Do not subclass built-in adapters like
MailIntakeGmailAdapterโ they are reference implementations and may change internally without notice.
๐ Custom auth providers
Subclass MailIntakeAuthProvider[T] to own a different credential flow:
Auth providers remain decoupled from adapter logic โ they only manage credentials.
๐๏ธ Custom credential stores
Implement the CredentialStore[T] contract for a new persistence backend:
The store abstraction keeps tokens out of config and rotates safely.
๐งช Wiring a custom backend
The reader only depends on the adapter contract, so the rest of the pipeline keeps working unchanged.
โ Extension checklist
- Implement the public contract โ never subclass built-in adapters.
- Keep transport in the adapter, parsing in parsers, auth in the provider.
- Return the provider-native payload and let parsers normalize it.
- Inject dependencies explicitly โ no global state or env reads.
๐ Read Next
- How to Use โ the built-in Gmail flow.
- Development โ running tests and docs.