Integrations

Name: Triora
Author: Triora

Review runtime configuration signals, safe fallbacks, and provider routes. Live sends, payments, OAuth sync, and webhooks still need separate approved proof.

4 of 9 runtime signals present

Configuration signals only

This page confirms setup signals only. It does not prove live provider delivery, payments, OAuth sync, webhooks, or sends. Keep provider proof in the Provider Proof Matrix and approved evidence runs.

Integrations setup center

This center helps owners and admins prepare integrations for connection, configuration, and later live-provider proof.

Owner/admin only

Requires owner approval before customer-facing enablement.

Ready to configure

Needs provider account

Needs live proof

Blocked before customer enablement

Coming after proof

Payments

1 provider

Stripe

Prepare subscription billing, checkout, billing portal, and webhook readiness for a later proof pass.

Needs live proof

Prerequisites

Owner-approved billing rollout plan
Stripe account access owned by the operator
Rollback notes for customer billing changes

Setup steps

1Review plans, seats, and billing portal expectations
2Prepare checkout and webhook verification notes
3Schedule a no-real-charge proof pass before enabling customers

Customer impact

Controls customer billing expectations, plan state, invoices, and payment recovery workflows.

Notifications

3 providers

Resend

Prepare transactional email setup for invites, digests, sharing notices, and account messages.

Needs provider account

Prerequisites

Owner-approved sending domain
Verified sender identity in the provider dashboard
Approved non-customer recipient for proof

Setup steps

1Confirm the sending purpose for each email family
2Prepare sender identity and domain verification notes
3Run one approved delivery proof before customer enablement

Customer impact

Affects account trust, invites, digest visibility, and delivery expectations for family, care, and business users.

Twilio

Prepare SMS configuration for transactional reminders only after consent and compliance are ready.

Blocked before customer enablement

Prerequisites

Compliant sender setup
Approved probe number
Customer consent and opt-out posture reviewed

Setup steps

1Document SMS use cases before any send path opens
2Prepare sender and compliance checklist
3Keep live sends blocked until delivery proof is captured

Customer impact

Can contact customer phone numbers, so proof, consent, and failure behavior must be clear first.

Firebase / FCM

Prepare push notification setup for device alerts, household reminders, and care-safe escalation paths.

Needs live proof

Prerequisites

Probe device owned by the operator
Notification permission flow reviewed
Safe notification copy approved

Setup steps

1Review client and server push readiness
2Prepare a non-customer probe device
3Capture receipt proof before customer notifications are enabled

Customer impact

Affects customer devices, notification permissions, and time-sensitive family, business, and care alerts.

Calendar

1 provider

Google Calendar

Prepare calendar connection flow for events, availability, scheduling, and later sync proof.

Needs provider account

Prerequisites

Test calendar account
Owner-approved OAuth consent posture
Disconnect and revoke expectations documented

Setup steps

1Review calendar scopes and customer-visible sync behavior
2Prepare a test calendar grant
3Prove create, update, sync, and revoke behavior in a separate lane

Customer impact

Calendar events can contain private household, care, and business context, so grants must stay review-first.

Accounting

1 provider

QuickBooks

Prepare accounting connection setup for invoices, imports, and later sandbox proof.

Blocked before customer enablement

Prerequisites

Sandbox accounting account
Hub owner approval for workspace accounting
Dry-run import expectations documented

Setup steps

1Choose personal or workspace accounting scope
2Prepare sandbox OAuth and first-import notes
3Keep customer sync blocked until sandbox proof is complete

Customer impact

Can affect clients, invoices, vendors, and accounting records, so live sync must stay proof-gated.

Deploy / Operations

1 provider

Vercel / Deploy

Prepare deploy readiness, production freshness, rollback posture, and operations review for a future approved lane.

Coming after proof

Prerequisites

Fresh branch and validation proof
Rollback path documented
Founder approval before any deploy action

Setup steps

1Review validation evidence before deploy consideration
2Confirm Preview readiness without exposing secret values
3Run deploy only in a separately approved operations lane

Customer impact

Controls release freshness, routing, availability, analytics, and customer-facing operational confidence.

Data / Platform

2 providers

Supabase

Prepare data, auth, storage, and realtime platform readiness without changing remote state from this screen.

Ready to configure

Prerequisites

Owner/admin role for platform decisions
RLS and migration evidence reviewed
Production data boundaries understood

Setup steps

1Review current data and auth proof posture
2Prepare platform checklist for the next approved backend lane
3Keep remote mutations outside this static setup center

Customer impact

Supports authentication, workspace data, permissions, and realtime collaboration across Triora.

Webhooks

Prepare inbound event setup for replay-safe provider callbacks and later signed-event proof.

Needs live proof

Prerequisites

Provider-specific event family selected
Replay and idempotency expectations documented
Signed fixture plan approved

Setup steps

1Select one provider event family at a time
2Prepare signed local fixtures before live callbacks
3Capture callback proof only in an approved provider lane

Customer impact

Provider events can update billing, sync, notification, and workspace state, so each event path needs proof.

Owner/admin guidance

Configure integrations one provider at a time so proof and rollback stay readable.
Run live proof only after an approved provider-specific plan exists.
Keep secrets out of chat, docs, screenshots, and support tickets.
Use the readiness cockpit below to separate setup intent from proof status.

Provider readiness cockpit

Static launch status for external integrations. This panel does not call providers, read environment files, or mark any provider production-ready without live proof.

need live proof

launch-blocking

Supabase

Core data and auth

Needs production deploy proof

Proof exists

Existing local schema and RLS evidence indicates the core backend is configured for app use.

Still needed

Production deploy freshness, role-safe access checks, and customer-launch verification remain pending.

Customer data

Yes - auth, workspace data, and permissions depend on this provider.

Next safe action

Recheck runtime status and RLS evidence after the approved production deploy proof pass.

Live proof required before launch

Stripe

Billing

Production proof pending

Proof exists

Local route and billing contract coverage exists; live charge and webhook delivery are not certified here.

Still needed

Founder-approved test checkout, webhook verification, and billing rollback notes before customer billing.

Customer data

Yes - billing state, subscriptions, invoices, and customer payment expectations.

Next safe action

Keep billing disabled for customers until a no-real-charge provider proof pass is scheduled.

Live proof required before launch

Resend

Email delivery

Do not enable for customers yet

Proof exists

Status-route evidence exists, but delivery remains mocked or unhealthy until sender setup is verified.

Still needed

Verified sender domain, approved test recipient, and dated inbox receipt proof.

Customer data

Yes - customer email delivery, deliverability, and notification trust.

Next safe action

Resolve sender verification first; then run one approved non-customer delivery proof.

Live proof required before launchDo not enable for customers yet

Twilio

SMS delivery

Do not enable for customers yet

Proof exists

Status-route evidence exists, but SMS delivery is not live-delivery-proven for launch.

Still needed

Compliant sender setup, approved probe number, and dated delivery receipt proof.

Customer data

Yes - customer phone numbers, consent, and transactional message expectations.

Next safe action

Keep SMS sends disabled until compliance and a founder-approved probe send are complete.

Live proof required before launchDo not enable for customers yet

Firebase/FCM

Push notifications

Needs live proof

Proof exists

Runtime/status proof indicates push configuration can be detected; no customer device delivery proof is claimed.

Still needed

Registered probe device token, approved notification send, and receipt evidence.

Customer data

Yes - customer devices, notification permissions, and time-sensitive alerts.

Next safe action

Use a non-customer probe device for one approved push delivery proof.

Live proof required before launch

Google Calendar

Calendar sync

Configured but not verified

Proof exists

Adapter and route behavior are covered locally; live OAuth grant and calendar sync proof are pending.

Still needed

Approved OAuth grant, webhook or sync callback proof, and revoke-path verification.

Customer data

Yes - calendar events can include private family, care, and business context.

Next safe action

Do not sync customer calendars until a test calendar grant proves create, update, and revoke behavior.

Live proof required before launchDo not enable for customers yet

QuickBooks

Accounting sync

Mocked only

Proof exists

Local accounting route and mock sync behavior are represented; live OAuth and import proof are not certified.

Still needed

Sandbox clients, OAuth grants, dry-run import counts, and safe disconnect proof.

Customer data

Yes - invoices, clients, vendors, and accounting records could be affected.

Next safe action

Keep accounting sync in mock or dry-run mode until sandbox OAuth proof is complete.

Live proof required before launch

Vercel/deploy

Hosting and release

Production proof pending

Proof exists

Repository checks and deployment-readiness notes exist, but this slice does not deploy or inspect provider dashboards.

Still needed

Approved deploy, production freshness check, and rollback-readiness confirmation.

Customer data

Yes - release freshness, routing, analytics, and availability depend on deploy state.

Next safe action

Rebase after parallel slices merge, then run the approved deploy-readiness checklist before PR.

Live proof required before launch

Webhooks

Inbound provider events

Mocked only

Proof exists

Local contracts cover expected webhook handling; signed live provider event delivery is not certified.

Still needed

Per-provider signed event fixtures, replay safety, idempotency evidence, and live callback proof.

Customer data

Yes - provider events can update billing, sync, delivery, and workspace state.

Next safe action

Add one provider webhook proof lane at a time with replay-safe local fixtures first.

Live proof required before launch

Email/SMS/push notification proof

Customer communications

Do not enable for customers yet

Proof exists

Notification cascade paths are locally represented, but combined email, SMS, and push delivery proof is pending.

Still needed

Approved probe recipients, delivery receipts, failure-mode notes, and customer opt-out guardrails.

Customer data

Yes - this can contact customers directly and expose private notification content.

Next safe action

Run separate non-customer proof passes for push, email, and SMS before enabling customer sends.

Live proof required before launchDo not enable for customers yet

Launch blockers visible

Resend, Twilio, Google Calendar, Email/SMS/push notification proof are blocked or customer-send sensitive. Needs live proof, production proof pending, and mocked-only states must remain visible before launch.

Launch readiness control room

Buyer and CTO launch review for provider proof, blocker visibility, and claim control. This is a static readiness surface, not a provider probe or production enablement switch.

blocker classes

safe proof steps

proof-complete rows

Launch blocker summary

Customer enablement remains blocked until proof is captured

Production provider proof pending

Runtime signals and local proof do not clear production launch readiness.

Live delivery proof pending

Email, SMS, push, payment, OAuth sync, and webhook paths need approved round trips.

OAuth grants pending

Calendar and accounting grants need sandbox or test-account proof before customer sync.

Webhook event proof pending

Signed provider callbacks need replay-safe proof before launch claims can change.

Customer-facing enablement blocked

Customer sends, billing, and sync stay blocked until provider proof is captured.

Claim-control panel

What we can and cannot claim

Safe claims

Provider readiness is tracked.
Mock/local proof exists for selected flows.
Live production proof is pending.

Cannot claim yet

Production integration readiness remains unproven.
Customer notification delivery remains unproven.
OAuth/accounting production sync remains unproven.
Customer provider enablement remains blocked.

Next safe proof steps

Future provider-proof slices stay one provider at a time

1Confirm current Preview/Production environment values without printing secrets.
2Run approved probe sends for email/SMS/push.
3Capture provider webhook event proof.
4Confirm OAuth grant and refresh behavior.
5Verify customer-data impact boundaries.
6Document one provider at a time.

Provider risk grouping

Readiness grouped from Slice 11A provider truth

Live-dev proven but production proof pending

Local or development proof exists, but it is not customer launch proof.

Mock-proven only

Local mocked contracts exist; live provider behavior is still unproven.

Configured but unverified

Configuration or runtime signals exist without full provider round-trip evidence.

Blocked before customer enablement

Customer-sensitive or launch-blocking provider work remains gated.

Buyer / CTO note

This cockpit is a launch-readiness control surface. It does not call providers, inspect secrets, or prove live delivery by itself.

Core Infrastructure

Supabase

Core Infrastructure

Runtime configured

Postgres database, row-level security, real-time subscriptions, and authentication. The backbone of every Triora workspace.

Runtime configuration is present; this label does not claim notification, payment, sync, or webhook delivery proof.

View docs

Google Gemini AI

Core Infrastructure

Requires setup

Powers Triora AI features: smart summaries, daily briefs, node suggestions, and the Triora ghost monitor.

Provider setup is incomplete; Triora keeps the experience in a safe fallback state.

View docs

Finance & Payments

Stripe

Finance & Payments

Configured, delivery pending

Subscription billing and plan enforcement support when Stripe keys and webhook verification are configured.

Runtime route is configured. Provider delivery, sync, payment, or webhook proof still requires an approved provider round trip.

View docs

Accounting

QuickBooks Online

Accounting

Requires setup

Invoice, expense, and account sync support for business workspaces when QuickBooks OAuth is configured and verified.

Provider setup is incomplete; Triora keeps the experience in a safe fallback state.

View docs

Calendar & Scheduling

Nylas Calendar

Calendar & Scheduling

Requires setup

Google Calendar, Outlook, and Apple Calendar support for event nodes, availability windows, and the integrated scheduler when OAuth grants are configured.

Provider setup is incomplete; Triora keeps the experience in a safe fallback state.

View docs

Communications

Twilio SMS

Communications

Requires setup

Outbound SMS alert support for task reminders, medication schedules, and household notifications after Twilio health and a probe number are verified.

Provider setup is incomplete; Triora keeps the experience in a safe fallback state.

View docs

Resend Email

Communications

Requires setup

Transactional email support for invites, password resets, digest reports, and sharing notifications after sender verification.

Provider setup is incomplete; Triora keeps the experience in a safe fallback state.

View docs

Firebase Push Notifications

Communications

Configured, delivery pending

Native push notification support for mobile and desktop after Firebase/VAPID config and a probe push token are verified.

Runtime route is configured. Provider delivery, sync, payment, or webhook proof still requires an approved provider round trip.

View docs

Home Automation

Samsung SmartThings

Home Automation

Configured, delivery pending

SmartThings device-event and command support when OAuth credentials, webhook secret, and device grants are configured.

Runtime route is configured. Provider delivery, sync, payment, or webhook proof still requires an approved provider round trip.

Connect Samsung SmartThings View docs

How to read configuration signals

Add the required variables in your development or hosting environment. Never paste secret values into Triora, chat, screenshots, or issue trackers. Configuration enables route signals; live sends, payments, webhooks, OAuth sync, and provider delivery still require separate approved proof.