In-Chat Connect Cards

There's a moment that used to be painful in every app-building tool: you ask for a feature that needs an external service, the tool says "to do this, you need to connect [Service]", and now you're juggling four browser tabs trying to sign up, find your keys, and paste them somewhere.

Appsanic does this differently. When the agent realises it needs credentials for a service, it stops, says why in one sentence, and drops a connect card right into the chat. The card has the service's logo, a one-line reason for asking, and a Connect button. Clicking it opens the connectors modal on the same page, already focused on that provider - you never leave the build while you connect. The card then detects the connection by itself and the build resumes.

This page covers how the cards work and what to do when one appears.

When you'll see one

A connect card shows up the moment the agent tries to use a service it doesn't yet have credentials for. Common moments:

• You ask for sign-in before connecting Supabase. The agent drops a Supabase connect card. "I need Supabase to handle sign-in and store user accounts."
• You ask for a database table without a connector. Same Supabase card.
• You ask for payments. A Stripe card.
• You ask for photo uploads without storage configured. Supabase Storage falls under the Supabase card.

You'll often see a connect card on your very first feature prompt in a fresh project. That's the moment the agent first realises it needs Supabase for anything stateful. Connect it once, the rest of the account flows freely.

Anatomy of the card

A connect card looks like:

• The service's logo (Supabase's green square, Stripe's purple, etc.).
• A name ("Supabase," "Stripe").
• A one-line reason in plain English: "I need Supabase to store user accounts and the recipes they save."
• A "You'll need: …" line when the agent knows exactly which keys are involved.
• A "Connect [Service]" button as the primary action.
• An "Open setup" link as a secondary path - it opens the full dashboard connector page in a new tab, with the step-by-step walkthrough alongside the form.

The card has a purple-tinted outline so it stands out from regular agent messages.

Connecting from the card

Click Connect.

The page's connectors modal opens directly at that provider - you never leave the build, and everything stays exactly where the agent paused. Inside you get the same connect surface the dashboard uses:

• One-click OAuth ("Connect with Supabase" / "Connect with Stripe") where the deployment has it configured. OAuth opens in a new tab, and the modal detects completion automatically. The Supabase flow includes a quick project-picker confirm step.
• Paste-keys fields as the always-available fallback, driven by the same field schema and validation as the dashboard page.
• A live test before anything is saved: Appsanic checks your keys against the real service first.

The moment you click Connect on the card, it flips to a waiting state: "Finish connecting and we'll continue automatically - this card updates the moment the connection lands."

How the card knows you're done

You don't have to tell it. Three detection layers run while the card waits:

1. Instant signal - connecting in the modal (or in another tab of the same browser) notifies the card immediately. Same-page connects land in one paint.
2. Polling fallback - while waiting, the card re-checks your connections every few seconds. This catches connects made from a different browser or device.
3. Manual check - an "I'm done - check now" button on the waiting card, for when you want to force a re-check right away. There's also a "Re-open setup" link in case you closed the tab.

Whichever layer fires first, the card flips to connected and the agent's build resumes from where it paused. No re-prompting needed - same task, same context, just now with the credentials it needs.

Escape hatch: the full setup page

If you'd rather connect with all the documentation in view, click Open setup on the card. That opens Dashboard → Connectors → [Service] in a new tab, which has:

• The full setup walkthrough - where to sign up, which page holds each key, what the common copy-paste mistakes are.
• The same connect form (OAuth + paste keys), so nothing differs except the surroundings.
• Connection management - status, Test connection, Disconnect, the Account access toggle, and the activity log.

Connect there, switch back to the build tab, and the card picks the connection up on its own. For services where you want extra context the first time (especially Supabase), the dashboard path is often more comfortable. See Supabase for the full first-time walkthrough.

What the agent does next

The moment the connection lands:

1. The agent had paused with the connect card as its last word.
2. The card detects the connection and the runtime sends the agent a synthetic message: "CONNECTOR CONNECTED: Supabase."
3. The agent reads that and resumes the original task.
4. As it resumes - and the first time it uses any connected service in a conversation - it says so briefly in its opening sentence: "Using your connected Supabase for sign-in…". When Account access is on, it announces account work up front.

This is one of the most useful UX bits of the builder. The connector step doesn't break your flow. It slots into it.

Common scenarios

"The agent wants me to connect Supabase but I'm not ready"

You can ignore the card. The agent is paused, not stuck. When you do connect (now or in five days), click Connect on the card and the build resumes from the same spot.

You can also tell the agent: "Don't worry about Supabase for now. Build a static version with mocked data." It'll continue with mocks. When you connect Supabase later, ask: "Now wire the real Supabase backend in."

"I connected in another tab but the card still says waiting"

Give it a few seconds - the polling fallback catches cross-browser connects on its own. If you're impatient, click "I'm done - check now". If the card still doesn't flip, verify the connection actually saved under Dashboard → Connectors (a failed key test means nothing was stored).

"I want to disconnect and reconnect with new keys"

Go to Dashboard → Connectors → [Service]. Click Disconnect (it asks you to confirm). The next time the agent needs the service, it'll show a fresh connect card, and you can enter new keys.

"Two different projects, same Supabase account"

That's fine - better than fine, it's the design. Connections are stored per account, not per project. Connect once, and every project in the account uses the same connection. If you want each project on its own Supabase project, create separate Supabase projects at supabase.com and switch the connection when you switch focus - or keep them in separate accounts.

Differences from the dashboard page

Two paths to the same destination:

• The dashboard page (Dashboard → Connectors → Supabase). You go there before the agent needs the service. Useful when you want to set things up proactively, follow the longer walkthrough, or manage an existing connection.
• The in-chat connect card: appears reactively, in the middle of a build, when the agent realises it needs a service. Opens the modal in place, no page-switch, build resumes automatically.

You can use either or both. The state is shared. Connecting from one place means the other immediately reflects the same connected status.

Under the hood (for engineers)

• The agent emits a connect_connector tool call with { provider_id, reason, required_fields? }. The runtime renders it as a terminal chat artefact - the connect card.
• Clicking Connect asks the page to open its connectors modal at that provider. If no modal host is mounted (the card rendered outside the build page), it falls back to opening the dashboard connector page in a new tab.
• The modal renders the same shared connect form as the dashboard page - one component owns field schema, validation, saved-secret handling, OAuth launch, and the live test, so the two surfaces can't drift.
• A successful save updates the shared connectors cache instantly and broadcasts to other tabs; the waiting card also polls /api/connectors every few seconds as a fallback.
• On detection, the host posts a synthetic CONNECTOR CONNECTED: <provider_id> message, which fires a fresh build job that picks up where the original paused.

Next

For the full Supabase walkthrough (which is what most users connect first), read Supabase. For the whole catalogue and how the dashboard pages work, read Connectors Overview.