Integrations

OpenScouter integrates with seven external services to handle payments, communication, AI inference, facial analysis, email delivery, scheduling, and data persistence. Each integration is described below with its role, configuration requirements, and failure behavior.

Stripe Connect

Stripe is used for payment processing and tester payouts. OpenScouter uses the Stripe Connect platform to enable direct payouts to tester bank accounts.

Role

Businesses pay for studies through Stripe. Funds are held in the OpenScouter Stripe account until the study is complete and findings are confirmed. At completion, the platform distributes payment to each tester’s connected Stripe account minus the platform fee.

Integration Points

Endpoint	Trigger	Description
POST /api/webhooks/stripe	Stripe sends events	Handles payment confirmation, payout status, and Connect account updates
POST /api/billing/checkout	Business creates a study	Creates a Stripe Checkout session for study payment
POST /api/billing/connect	Tester onboards	Initiates Stripe Connect onboarding for a new tester
POST /api/billing/payout	Study complete	Triggers payout to tester Stripe accounts

Webhook Events Handled

• checkout.session.completed - Study payment confirmed; study transitions to active status
• account.updated - Tester Connect account verification status changed
• payout.paid - Payout successfully delivered to tester bank
• payout.failed - Payout failed; triggers retry and notification

Webhook payloads are verified using HMAC-SHA256 with the Stripe webhook signing secret. See the Authentication page for verification implementation details.

Note

Stripe Connect requires testers to complete identity verification before they can receive payouts. Testers who have not completed verification are eligible for studies but will not receive payment until verification is complete.

Telegram Bot

Telegram is the primary communication channel between OpenScouter and testers. Testers do not log in to a notification dashboard. All study offers, status updates, and reminders are delivered via Telegram.

Role

When a study is matched to a tester, the platform sends a Telegram message with the study brief, compensation amount, and an accept/decline link. Reminders are sent 24 hours and 2 hours before a test is due. Post-test confirmation prompts are also delivered via Telegram.

Integration Points

The integration uses the Telegram Bot API. The bot is configured with a webhook URL pointing to POST /api/webhooks/telegram.

Trigger	Bot Action
Study match	Send offer message with study details
Offer expires in 2h	Send reminder
Tester accepts	Confirm acceptance, send test token
Test due in 2h	Send preparation reminder
Test complete	Send confirmation request link
Payout processed	Send payment confirmation

Configuration

The bot requires a TELEGRAM_BOT_TOKEN environment variable. Messages are sent using the sendMessage method with parse_mode: MarkdownV2 for structured formatting.

Caution

Telegram does not support end-to-end encryption in bot messages by default. Study briefs sent via Telegram should not contain sensitive business information. Detailed study materials are accessed through the authenticated tester dashboard, not via Telegram messages.

DeepFace

DeepFace is the facial expression analysis engine used to process tester facial snapshots captured during tests.

Role

The Chrome extension sends JPEG snapshots to the API during an active test. The API forwards each snapshot to the DeepFace service, which returns emotion labels, confidence scores, and Action Unit values. The results are stored as facial_snapshots records.

Integration Points

DeepFace runs as a self-hosted FastAPI service. The API communicates with it over an internal network endpoint.

POST /analyze
Content-Type: multipart/form-data

{
  "actions": ["emotion"],
  "enforce_detection": false,
  "detector_backend": "retinaface"
}

The enforce_detection: false setting prevents errors when no face is detected in a frame. When the response indicates no face was found, the snapshot is stored with face_detected = false and excluded from analysis.

The service processes snapshots synchronously. The API waits for the DeepFace response before storing the result, because downstream analysis depends on the emotion labels.

Failure Behavior

If the DeepFace service is unavailable or returns an error, the snapshot is stored with emotion = null and face_detected = false. The test continues. Emotion data is treated as optional; the corroboration engine can still produce findings from browser events and voice transcripts alone.

Resend

Resend handles transactional email delivery. Resend is used for business-facing communications only. Tester notifications go via Telegram.

Role

Email Type	Trigger
Study commissioned	Business completes payment
Tester matched	Tester accepts study offer
Report ready	Synthesizer agent completes
Invoice	End of billing period
Password reset	User requests reset
Magic link	User requests passwordless login

Configuration

The Resend SDK is configured with a RESEND_API_KEY environment variable. All transactional emails use React Email templates rendered server-side before sending. Templates are stored in src/emails/.

Calendly

Calendly is used for scheduling synchronous review calls between businesses and OpenScouter’s accessibility consultants. Scheduled calls are optional and available on paid plans.

Role

After a study report is delivered, the business dashboard shows an option to schedule a review call. Clicking this link opens an embedded Calendly widget pre-filled with the business’s account details. When a meeting is booked, Calendly sends a webhook to POST /api/webhooks/calendly to record the booking in the OpenScouter database.

Integration Points

The Calendly integration uses the Calendly v2 API for event type management and the Calendly webhook API for booking notifications.

Webhook payloads are verified using the Calendly-Webhook-Signature header.

Supabase

Supabase provides the PostgreSQL database, authentication, Row-Level Security, storage, and real-time subscriptions. Although Supabase is the foundational data layer rather than a third-party integration in the traditional sense, it has distinct configuration requirements.

Role

Supabase Service	Usage
PostgreSQL	All structured data storage
Auth	User sessions, JWT issuance, OAuth
Row-Level Security	Data isolation between organizations
Storage	Screen recording clips, report PDFs, snapshot archives
Realtime	Live test progress updates in the business dashboard

Configuration

Supabase is configured with the following environment variables:

• NEXT_PUBLIC_SUPABASE_URL - Public Supabase project URL
• NEXT_PUBLIC_SUPABASE_ANON_KEY - Public anon key for client-side requests
• SUPABASE_SERVICE_ROLE_KEY - Service role key for server-side administrative operations

The service role key bypasses RLS. It is used only in server-side API routes where the operation legitimately needs to span multiple organizations, such as the Synthesizer agent aggregating data across all testers in a study.

Caution

The SUPABASE_SERVICE_ROLE_KEY must never be exposed to the browser. It is used only in API routes. Any route using the service role key should include a comment explaining why RLS bypass is necessary for that operation.

AI Providers

OpenScouter uses three AI providers for the 4-agent analysis pipeline: OpenAI, Anthropic (Claude), and Google Gemini. The platform implements automatic failover across providers to ensure high availability.

Role

All four agents in the AI pipeline use these providers for inference. The platform routes requests to the primary provider and falls back to alternative providers if the primary is unavailable or returns an error. Voice transcript segments flagged as containing personally identifiable information are excluded from AI analysis until they have been sanitised.

Configuration

Each provider is configured with its own API key environment variable. The platform selects the appropriate provider based on availability and the failover strategy defined in the agent runner.

Failure Behavior

If all AI providers are unavailable, affected analysis steps are queued for retry. A background job retries unprocessed segments every 15 minutes.