Integrations
Pair supports a broad set of external services without making integrations feel like a separate subsystem bolted onto the framework.
This area is a plus of the framework, but it should be read as a family of equal capabilities:
- storage and file delivery
- maps, geocoding, and places
- mail delivery
- payments
- messaging and notifications
- telephony and contact-center services
Use this page as the hub for choosing the right integration page and understanding how these services fit into Pair projects.
Integration pages in the wiki usually fall into one of these shapes:
- service reference page Focused on constructor, main methods, configuration, and common usage.
- low-level client/helper page Useful when a higher-level service is built on top of a reusable transport layer.
- integration cookbook page Focused on architecture patterns, jobs, webhooks, background sync, and production behavior.
Not every external service needs all three layers. Some integrations are naturally small and need one reference page; others are split into multiple pages because the implementation has both transport and project-level integration concerns.
- AmazonS3 Server-side wrapper for S3-compatible object storage operations.
- GoogleMaps Browser-side helper for loading Pair's Google Maps assets and frontend integration.
- GoogleMapsClient Low-level HTTP client shared by the server-side Google Maps services.
- GoogleGeocoder Server-side geocoding wrapper.
- GooglePlacesService Server-side Places API wrapper.
- GoogleAddress Form/input-oriented integration for address autocomplete and maps-assisted UX.
- Mailer Base abstraction for mail senders.
- SendMail Concrete mail service using a sendmail-style transport.
- SmtpMailer Concrete SMTP-based mailer.
- AmazonSes AWS SES mail sender implementation.
- StripeGateway Wrapper for common Stripe payment operations.
- TelegramBotClient Main Telegram Bot API client for generic calls, webhook helpers, messaging, and file downloads.
- WhatsAppCloudClient WhatsApp Cloud API client for outbound messaging, media handling, webhook verification, and normalized events.
- AircallClient Service reference for the Aircall REST API wrapper.
- AircallAPI Integration cookbook for jobs, webhooks, sync flows, and production patterns around Aircall.
Use Integrations when:
- you want the overview of supported external services
- you need to decide which page to read first
- you want a neutral map of the integration surface of Pair
Use a service reference page when:
- you already know the provider
- you need constructor details, config, and method-level examples
Use an integration cookbook page when:
- the provider needs background sync, webhooks, retries, or production architecture guidance
Some integrations keep webhook and operational guidance directly in the class page, as happens with WhatsAppCloudClient. Others, such as AircallAPI, are large enough to justify a separate cookbook page. This is a documentation-shape difference, not a signal that one provider is more central to Pair than the others.
Across services, the recurring structure is usually:
- a framework service/helper that wraps the external provider
- optional project service classes that map provider behavior to domain behavior
- controllers, jobs, or workers that call the project service
This keeps Pair controllers thin and isolates provider-specific behavior where it belongs.
