Build and test the TeleScribe connection
Who this is for
The TeleScribe developer implementing professional reference access for a signed-in clinician. Abe AI owns the service, access and update preferences; TeleScribe is the host. No consultation transcript, patient chart or patient identifier belongs in this integration.
This is an implementation handoff, not a declaration that the universal widget or paid onboarding is ready. The existing native page is at /scribe/updates. The compact console panel and universal expandable widget are not yet implemented. The user guide is the acceptance journey your implementation must support.
The host observations below were recorded on 2 October 2026 and have not been rechecked in the host application during this review. Its developer must confirm current behaviour before applying any host repair. Abe's team does not inspect or modify the host repository to complete its provider service. Start with the current global developer guide, widget contract and Stripe setup. A vendor example does not replace those shared requirements.
Start here
1. Read the existing implementation before adding an embed
In the TeleScribe repository, inspect these paths:
| File or directory | Responsibility |
|---|---|
src/app/scribe/updates/page.tsx | Signed-in page reached from Professional updates in the side navigation. |
src/components/abe/UpdatesPanel.tsx | Feature selection, permission window, search, selected inbox and disconnection controls. |
src/lib/abe/runtime.ts | Verified host identity, practice mapping, one-use linking, encrypted delegation and due-update requests. |
src/lib/abe/client.ts | Abe confidential-host request and exchange contract. |
src/lib/abe/consumer.ts, delivery.ts, inbox.ts | Preference/delivery adapter, receipt persistence and permission-bound inbox. |
src/lib/abe/connection-store.ts | Server-side encrypted credentials bound to both account identities, organisation and app. |
src/app/api/abe/ | TeleScribe's authenticated browser-facing endpoints. |
docs/abe-connection.md | Existing host implementation notes and local checks. |
Use that native component for the current side-nav screen. Do not embed Abe's whole console in an iframe or place an organisation API key in the browser. The existing /embed/evidence surface is a distinct reference-library embed, not the selected-updates widget. There is no installation snippet for a universal package-aware widget yet.
2. Recheck the previously observed account-access failure
On 2 October 2026 the signed-in TeleScribe page displayed Connection setup is unavailable. A read-only request to GET /api/abe/updates returned 503 with membership_unavailable. The runtime's hostContext() stops when its authenticated practice lookup fails.
A read-only database probe with a synthetic authenticated identity reproduced 42P17: infinite recursion detected in policy for relation "practice_members". The practice access policies inspected then referred back to the membership relation. This was the verified reason that connection test could not start on 2 October. It is not a current health check of the host, and purchasing a Stripe discount would not repair that observed membership failure.
If the host developer reproduces this failure, prepare a bounded correction to the practice-membership lookup/access path. Keep the verified signed-in user as the authority; never accept a browser-supplied user or practice ID. Preserve active-membership checks and owner checks. Do not select an arbitrary practice when multiple authorised practices exist. Database policy changes need explicit live approval, and changing to a server-side lookup requires its own authorisation review. Do not suppress the error or bypass organisation checks to make the screen appear healthy.
Before release, prove the chosen practice for an ordinary member and owner, refusal for another user's practice, inactive-membership refusal, multi-practice handling and error handling. Then read the actual signed-in endpoint again. No live access policy was changed by writing this guide.
3. Check server configuration and registration
Existing first-party TeleScribe registration uses app ID telescribe-professional-updates, origin https://www.telescribe.com.au and exact return URL https://www.telescribe.com.au/scribe/updates. Verify the active deployment and registration before changing configuration. The TeleScribe repository's historical local Vercel project link is stale; identify the project serving the real domain before deploying.
Required host server variables are ABE_CONNECT_ENABLED, ABE_HOST_ORIGIN, ABE_APP_ID, ABE_CLIENT_SECRET, ABE_CREDENTIAL_ENCRYPTION_KEY and ABE_API_ORIGIN. Their existing values must be verified securely, without printing secrets. Credentials belong only on the server. They are not values a clinician types into a widget.
Confirm the existing host connection, pending-link and professional-notification tables and their restricted access. Do not reapply a migration because a guide lists the tables. A registered app, a configured environment and a funded licence are separate from an individual's permission.
4. Reuse the actual connection contract
| Step | Contract |
|---|---|
| Begin in the host | Authenticated TeleScribe backend requests POST /api/connect/requests with appId, exact redirectUri, selected scopes and a random host-bound state; application credential goes in x-abe-client-secret. |
| User permission | Open the returned consentUrl from TeleScribe. The person signs in to Abe, chooses access and expiry, confirms or declines. |
| Receive approval | Validate exact Abe origin, the requesting popup, message type abe-connect-approved, version 1 and the original state before forwarding the code to the authenticated host backend. |
| Exchange once | Backend sends POST /api/connect/link with appId, exact host origin and one-use code, using its server credential. Validate the returned subject, organisation, scopes and expiry. |
| Bind identity | Bind the returned Abe subject to the verified TeleScribe user and practice. Encrypt and store delegation server-side; do not match accounts by email. |
| Read permitted access | GET /api/connect/discovery, using delegation in x-abe-evidence-session and exact host origin in x-abe-evidence-origin. |
| Search, if approved | GET /api/partner/v1/evidence/search?question=... with those same delegated headers. Keep questions non-patient. |
| Stop access | Host revokes locally, then PATCH /api/connect/connection with {action: 'revoke', confirmed: true} and delegated headers. Preserve and reconcile an uncertain remote result. |
The browser talks only to the host's authenticated /api/abe/ routes; it never receives a client secret or delegation token. An organisation MCP key is not a substitute for this person's delegation. Individual generic OAuth remains unavailable until its separate provider contract is accepted.
Feature choices map as follows:
| TeleScribe choice | Requested scopes |
|---|---|
| Browse and search evidence | evidence:read |
| Manage my update preferences | evidence:preferences:read, evidence:preferences:write |
| Receive my selected updates here | evidence:delivery |
Nothing is preselected. Connecting does not activate alerts. Use the person's existing Abe preferences screen for criteria, exclusions, timezone, quiet hours, timing and destination. The current host's Check selected updates calls its due-delivery path on request; a new automatic delivery runner is unfinished and requires separate acceptance.
5. Complete the shared widget separately
The existing Abe widget model supplies a feature-selection foundation. The finished shared surface must derive visible features from current service readiness, funded capabilities, the person's permissions and their choices. Hiding a tile is not access enforcement: every server request must recheck those conditions. Downgrade, licence expiry and revocation must remove affected access while preserving saved preferences and independently funded access.
Build an authenticated responsive surface with source-linked feed summaries, search, connection state, funding state, permission controls and an accessible route to update preferences. Only include services with accepted operations. Retain the existing Beta professional-development finder; adding it to the host requires its own permitted capability and implementation. Do not advertise clinical-evidence updating or treatment advice. Source-link rights do not authorise full-text copying.
What success looks like
Run the TeleScribe user steps with a normal non-patient test account. Record the exact deployment and dated results:
- The signed-in updates route loads the correct person's connection state without a membership error.
- Empty feature selection cannot start a connection; decline and a closed or blocked popup leave no completed connection.
- Approved selected scopes return to the same host user and organisation; mismatched state, account or origin is refused.
- A permitted general search produces inspectable evidence or an honest gap. A missing scope is refused.
- The person chooses and activates an alert with their criteria, timing and TeleScribe destination. No subscription is created merely by connecting or funding access.
- An actually due matching update is persisted once in the intended inbox with its receipt. Repeated checks do not duplicate it. Empty results are not delivery acceptance.
- Pausing prevents new deliveries. Another person or practice cannot see the inbox or private preferences.
- Disconnect clears local access; remote revocation is confirmed or remains visibly pending. Old delegation is refused after confirmed revocation.
- Subscription tests separately prove purchase, failed payment, downgrade, cancellation and resulting access. Use a prepared Stripe sandbox or test-mode environment, not a live 100% discount as payment proof.
Owner-sponsored access is sufficient for steps 1–8. It does not prove step 9. Automatic chosen-time delivery and the full expandable widget each need their own acceptance record. Do not tick a result based only on mocks, configuration or a deployment marked ready.
If it does not work
Return a useful safe error to the user and retain a redacted operational record. A 401 is authentication, 402 is missing current feature funding, 403 is forbidden access, 409 is a state/revision conflict, 429 requires rate-limit handling, and 503 is unavailable service or verification. Do not solve a failed personal connection by changing to an organisation key.
If the previously observed membership_unavailable failure is still present, the host developer must repair and verify its practice-access path before testing consent. Ask support with the route, error code, deployment and time. Do not include secrets, patient content, search text or private preferences. See Troubleshooting.
Stop or change your choices
The user may pause alerts, disconnect the app or cancel funding separately. Preserve the distinction and saved choices. Do not auto-reconnect, activate notifications or replay withheld updates when access returns. Keep uncertain external outcomes for reconciliation rather than retrying blindly. See Privacy and permissions and Manage and cancel.