Develop an authorised Abe connection
Who this is for
This guide is for a developer acting for an authorised software owner. The existing confidential-host connection requires application registration and personal consent. An organisation service key is a separate service identity. Individual OAuth remains unavailable because the provider and named-client acceptance are incomplete. None of these identities may be substituted for another.
Choose your integration
The separate course-search engine check now has an operator producer that executes bounded public API requests and retains the resulting original check. It requires the actual deployed implementation version; its operator route is deployed. It does not approve a host interface, source use, metering or payments. Your integration must pass those checks separately before subscriber access can be offered.
Start with the shared connection steps below, then follow the relevant guide: Website widget, Software API, MCP, Telegram, Notion or n8n. These guides describe different contracts and current limits; they do not establish that every channel is ready.
Application-specific examples sit under Use Abe in other apps. The shared provider contract is defined in the Website widget and Software API guides. Abe owns the provider and its example test application; the outside software developer owns their application's integration. The complete authenticated widget and purchase journey remain unfinished.
Start here
- Agree the non-patient purpose, intended users, exact organisation and smallest required read permissions with the owner. Use Services and access; a catalogue entry describes a service rather than granting it.
- Ask the authorised organisation owner to request registration at Application access. Supply the application's exact HTTPS origins and exact return URLs. An origin is the application's own address, not Abe's address. Registration stays pending until ownership verification.
- Keep the provisioned application credential server-side. It must never appear in a browser bundle, URL, workflow property, chat, log or screenshot. Rotation invalidates the previous credential.
- For the supported confidential-host flow, begin the permission request from the host's authenticated session. Open the returned Abe permission screen; the person chooses scopes and expiry or declines. Validate the returning window, exact Abe origin and the host's stored request state before sending the short-lived code to that same user's backend.
- The host backend performs the one-use exchange with its own credential and exact registered origin. Bind the returned verified identity to that authenticated host user, then store the delegation encrypted on the server. A user identity supplied by a page or tool argument is not proof. Opening consent directly without the requesting host does not complete this flow.
- Check permission and current service access at every protected call and immediately before any permitted delivery. Read API for contracts and failures. Do not construct personal OAuth settings from the confidential-host flow; the generic provider is still unavailable.
Only source representations permitted for that audience and purpose may leave Abe. Permission to download or ingest material does not authorise redistribution of its body. Personal search text and private alert criteria remain private. Patient charts must not choose professional interests or enter shared reference channels.
The update widget now derives its private source selector from the same selected current funding deployment. It independently checks the current registry before and after reading updates, limits output to those source identities and permitted fields, and refuses withdrawn or changed source permission. An updates licence alone cannot disclose the feed. This source-output repair is deployed. A genuine Department of Health source and engine check succeeded on 6 October 2026; those bounded checks do not complete a customer connection or automatic delivery.
Record browsing-only owner access
Abe's authorised platform owner can record a no-charge first-party allocation in Application access. The owner screen submits an explicit version: 2 to POST /api/connect/licences, with confirm: true and the exact licence fields: id, organisationId, capabilities, state, expiresAt, provenance, referenceId and revision. For browsing only, the capability is updates.read; it does not include notification permissions. Identifiers and evidence references must be canonical, and the original licence must be current. Missing or version-one requests retain the existing four-capability contract. An API key, foreign website or unconfirmed request cannot issue an allocation.
This is an Abe operator operation, not a free-access endpoint for outside subscribers. The owner then approves the separate owner terms. Service acceptance, personal consent and the encrypted host connection still apply. Outside developers keep using the provider connection below and do not import Abe's private funding modules.
Shared widget implementation contract
This is the implemented provider transport, not an accepted installation recipe. The default Abe widget runtime now reads current account membership, retained permissions and independently qualified funding. The signed-in GET /api/connect/access-summary route provides strict account discovery with a verified application origin. Widget discovery separately displays an unselected service as unavailable when its funding check reports unavailable; selected service failures still reject the snapshot. This does not issue funding, approve consent or enable checkout. Genuine funding and Abe's reference consumer still require normal-user acceptance before a host developer can rely on the full widget.
Abe's action-service entry points also compose independent original checks and current staff delegation. A saved deployment copy cannot approve itself: withdrawing an original check or losing the issuing administrator's authority can prevent an operation. The server-side purchase reader uses these originals and requires a recorded current account membership; a read-only practice profile is insufficient. This composition does not activate payment or complete a customer purchase. Outside developers use the documented provider routes rather than importing Abe's private server modules.
| Stage | Implemented provider contract |
|---|---|
| Request permission | Host backend sends POST /api/connect/requests with registered appId, exact redirectUri, selected scopes and host-bound random state. Its application credential uses x-abe-client-secret. The browser opens the returned consentUrl. |
| Accept the return | Validate the requesting popup, exact Abe origin, message type abe-connect-approved, version 1 and original state. Forward the short-lived code only to the same authenticated host user's backend. |
| Exchange once | Host backend sends POST /api/connect/link with appId, exact host origin and one-use code, with its application credential. Bind the returned Abe identity and organisation to the current host user. Keep the delegation encrypted on the server. |
| Request a widget hand-off | Host backend sends POST /api/connect/widget/bootstrap with contextId derived from that verified connection. Use x-abe-client-secret, x-abe-evidence-session and the exact registered x-abe-evidence-origin. This is server-to-server: do not forward browser cookies or browser Origin headers. |
| Load the neutral frame | Use the returned frameUrl, which selects the registered app and parent origin. It identifies no subscriber. Never add a user token or credential to that address. |
| Hand over the one-use nonce | After validating ready from the exact frame window and Abe origin, send the returned nonce only to that window with exact Abe target origin. The message has version 1, source abe-widget, type bootstrap and payload containing only nonce. Do not use a wildcard target origin. |
| Let Abe resolve private access | The Abe frame exchanges at POST /api/connect/widget/exchange, then reads GET /api/connect/widget/session. The frame keeps its short-lived session in memory. The parent must not receive that credential, private search results or the private snapshot. |
| Browse permitted updates | The Abe frame uses POST /api/connect/widget/updates. Browsing requires the selected read permission and valid access; notification permission is a separate choice. Source representation remains bounded by its approval. |
| Save display choices | The Abe frame uses POST /api/connect/widget/frame-preferences with its in-memory credential, current snapshot revision and presentation revision. Abe saves only module visibility and order for that verified person and workspace. The host never receives or submits this private credential. |
| Search courses | The Abe frame uses POST /api/connect/widget/courses with the current private frame connection and selected catalogue permission. A new search or next page uses the package's search allowance; deliberate recovery keeps the same original request. |
| Open course details | The Abe frame uses POST /api/connect/widget/course-detail with the same connection and separate course-detail permission. Loading details also uses the search allowance. An interrupted reply exposes deliberate same-request recovery; it must not become an automatic replacement request. |
| End or replace access | Remove the frame and discard pending hand-offs locally. Revoke the host connection using the existing confirmed connection contract, reconcile an uncertain result and prove the old delegation is denied. Expiry or account switching must clear old private content. |
Do not iframe the signed-in Abe console, identify a subscriber from an email address, substitute an organisation service key for personal consent or treat a display preference as permission. Hiding a module changes presentation; every protected operation independently checks access.
Hide, show and reorder controls use the same shared component in the preview and authenticated frame. The preview uses demonstration data; it does not establish real funding or saving. A failed save may have committed, so reconnect and inspect current settings before repeating it. Abe prevents a new save submission after the request deadline or frame expiry, and does not automatically retry. See Arrange your panel.
Before releasing a named host, retain the normal-user acceptance record for sign-in, decline, selected scopes, correct funding, actual source-backed browsing, pause, expiry, account change and disconnection. Record its exact deployment. Abe's provider test does not certify another application's integration. The Website widget guide explains what is still required.
Catalogue cursors bind the search filters, not the actor. Every continuation still requires the current frame, catalogue permission, funding and rate checks. Course-detail permission is separate from catalogue permission. The final course operation reacquires PD-specific funding after the last generic frame check; another funded service cannot substitute for it.
Host navigation responsibilities
Explicit official-update browsing permission
The released implementation adds a separate read permission, updates:read, for the updates.read feature. It is distinct from saved notification choices and delivery permission. Registration through Application access offers it with nothing preselected and submits the explicit version-two registration contract.
A confidential host that needs this permission sends version: 2 with POST /api/connect/requests, alongside its registered appId, exact redirectUri, selected scopes and unpredictable host-bound state. The application secret stays in the server's x-abe-client-secret header. For browsing alone, request only scopes: ["updates:read"]. Open the returned consentUrl exactly; its version=2 binds the permission window to the separate request owner. The person still chooses permissions, expiry and confirmation.
The permission page uses GET /api/connect/consent?request=<id>&version=2 and sends numeric version: 2 on its approval POST. Missing version selects the unchanged legacy flow, which cannot approve updates:read. Unsupported versions are refused; there is no automatic promotion of legacy requests. Both the request display and approval recheck the current application, exact return URL and declared features. Removing that return URL invalidates an outstanding request even if its origin remains registered.
Version-two requests use separate private storage, expire after ten minutes and can be consumed only once. The existing confidential link exchange and widget frame hand-off remain unchanged. Request creation does not create a grant, funded allocation or alert; the protected approval owner independently checks membership and current licensing.
After exchanging the consent code on your server, check a browsing-only connection with GET /api/connect/connection?version=2 using the confidential application credential and that person's delegated connection token. This explicit version-two read includes updates:read and rechecks current membership, funded access, grant and source permissions. Omitting the version uses the legacy connection check and cannot discover browsing-only access. Unsupported versions are refused. Revoking the connection still uses the existing confirmed PATCH /api/connect/connection; display settings and billing are separate.
Release status: the explicit version-two connection and its reviewed database changes are released. Abe’s deployed reference consumer uses this path. Complete signed-in browsing, display-saving, reopening and disconnection verification remains in progress; payment and external-host acceptance remain separate.
The host developer owns how the person returns to their application and opens companion Abe pages. Validate the frame's requesting window and exact Abe origin before responding to a navigation message. Use the verified provider origin and fixed service mapping; do not accept an arbitrary posted destination or expose the private frame session to the parent.
The Abe-owned reference application's current companion destinations are:
| Purpose | Abe destination |
|---|---|
| Choose sources, topics and notification preferences | /console/evidence-alerts |
| Open the separate professional-development finder | /professional-development |
| Open rules-and-standards search | /console/library |
| Open practice governance | /console |
| Inspect or revoke the person's app permission | /console/connections |
The frame also provides Open your Abe connections. Current rules-and-standards and governance links open Abe rather than perform those operations inside the frame. The reference app's Application and owner access setup leads to Application access; this is an operator prerequisite, not a subscriber credential form. Use Try the Abe reference application for the exact eight access choices and consent controls.
Other hosts need their own navigation, verified user/workspace mapping and registered origins. The reference application's success cannot certify their installation. Its local preference owner tests prove retained Hide, Show, reorder and reopen under declared synthetic member inputs. The separate local course browser test passed search, details, explicit same-request recovery, source-withdrawal refusal and genuine confirmed disconnection; its authentication, initial funding and source permissions were synthetic. Neither proves the complete deployed signed-in journey. Preserve unavailable and uncertain states rather than substituting a preview, an old result or another user's access.
Abe reference application setup
The Abe frame owns POST /api/connect/widget/courses. This is a same-origin private frame operation, not a public host endpoint. It requires the in-memory frame session and registered parent origin, current pd.search access and pd:catalogue:read permission. The frame sends a strict {operationId, query: {...}} body using the existing PD query fields. It creates a new UUID for operationId only for a deliberate new search or next page, then keeps that UUID and exact query in the frame while the request is unresolved. Check previous search reuses the same operation UUID and query to recover that request; it does not start a new search. The frame does not retry automatically. Recovery must not replace the original request with a new UUID. If the person deliberately selects Find courses again, the frame starts a new search with a new UUID; it does not recover or erase the previous operation. Check the previous search first when its outcome is uncertain. Editing filters or closing the whole connection clears the frame's temporary recovery reference, without erasing a committed operation or refunding its allowance. The identifier is a request reference, not authority for identity, funding or a result. A host must not copy or forward the frame credential. The backend uses the existing course service, private actor/context/app rate key, cursor secret and Jev relevance profile; missing evaluated Jev configuration is reported honestly. Revocation, changed snapshot or expiry during the operation withholds the result. No public-preview key or browser cookie replaces subscriber access.
The latest locally browser-tested repair retains four raw public course choices and the unresolved original operation/query in the continuing Abe frame during READY display revisions and module hide/show. Results and details remain mounted-component state and are discarded. Recovery is click-only; a late abandoned response cannot publish results or erase a newer pending selection. The locally implemented correlated renewal keeps those public choices in the same provider document while old results are hidden. Only a new private snapshot matching the resolved connection identity restores the panel. Other non-ready states, manual new bootstrap, verified account/workspace change, origin change or frame close clear the draft. Release and normal subscriber acceptance remain outstanding.
The private course response is distinct from the unchanged public v1 catalogue. Title, provider, delivery and other source fields may be omitted by the owning display permission. The frame supports an approved course link with required attribution without inventing missing metadata. Private source identities stay in Abe and never become browser-supplied authority. Relevance processing uses a separately approved source projection; display permission is not external-processing permission. Exact member and field qualification runs before optional checking and again before disclosure. The attribution reader and related private subscriber database functions were installed and read back on 4 October 2026. Installation did not create source permissions or prove the normal subscriber journey.
For official updates, Abe's operator now has a released source-original operation that reads the current reviewed registry itself, binds the exact app, origin, environment, source version and selected representation, and retains only that source observation. A submitted passed report cannot replace it. It does not create interface, engine, usage, funding or personal-permission checks. The shared original reader also independently rechecks the current source policy before registration, discovery or funding can use the original. Professional-development source permissions continue through their separate owning review service. These additions are released; complete operator/subscriber acceptance remains under verification; a retained original alone cannot make an integration ready. Uncertain source writes have an exact retained operation identity for reconciliation and must not be blindly repeated.
Abe's /connect-abe/test-application is a reference host for the confidential connection described above. The new explicit version-two backend lives at /api/connect/example/read; it accepts only a signed-in Abe session and same-origin mutations. Posted user or organisation IDs and API keys cannot substitute for that session. It uses the workspace resolved by that session. This path is released; its complete deployed user journey remains under verification. The existing /api/connect/example remains the legacy path and does not accept updates:read. New sessions use a separate private version-two table; no old session or consent is promoted. Requests to /api/connect/requests explicitly include version: 2; the permission URL carries version=2. Browse permission, saved preferences and delivery permission are separate, unchecked choices. The frame handshake remains version one; it is not a grant version.
The operator must register and verify a dedicated reference application through the existing authorised application workflow. Its origin is the canonical Abe HTTPS origin and its exact return URL is that origin plus /connect-abe/test-application. Declare only the service interfaces actually supported; registration does not supply service acceptance, funding or personal consent. Never reuse another vendor's registration.
Apply the reviewed private consumer-session migration to the intended Abe database and read back its role restrictions before enabling the test. Configure these two server variables separately in that Abe environment:
| Server setting | Meaning |
|---|---|
ABE_EXAMPLE_APP_ID | ID of that verified dedicated application. |
ABE_EXAMPLE_CLIENT_SECRET | Its confidential server credential. Keep it in the protected environment store; never show it in a guide, browser or log. |
The existing connection gate and canonical origin must already be correct. The implementation does not set these variables, register an application, issue an owner allocation or activate alerts automatically. Without both example settings, the signed-in page explains that setup is required.
On 4 October 2026, the dedicated Abe reference registration was activated and both server settings were stored in the production environment. On 6 October, the signed-in production reference page verified that the deployed application consumes those settings. This configuration checkpoint does not grant funding, approve the user's permissions or establish a completed connection. Other applications still require their own registration and protected server settings.
The example server retains pending state, binds the exchange to the authenticated Abe user and workspace, and encrypts the delegation using a separate purpose-derived key from the application credential. Rotation invalidates earlier encrypted sessions and requires reconnection. The browser receives only public connection state and a short-lived hand-off nonce. It never receives the delegation or client credential. The reusable host protocol is implemented in src/lib/connect-abe/widget-host.ts; the confidential reference backend is in src/lib/connect-abe/example-consumer.ts.
The historical 5 October production read-back confirmed the reference registration was active. At that time it found zero accepted application deployments, commercial offer contracts, original funding roots, owner approvals, subscriber grants and reference sessions. Do not register a duplicate app or insert test approvals to bypass those prerequisites. Establish independently verified engine, source, interface and usage acceptance for the exact app, origin and environment, then genuine funding and explicit owner terms. Source automation being healthy does not establish this service acceptance. The 6 October signed-in check verified /api/connect/example/read reports configured:true without exposing secret values; the saved configuration checkpoint alone does not prove that the current deployment consumes it.
On 6 October 2026, genuine no-charge owner funding, explicit owner terms and a bounded accepted reference deployment were recorded. The owner approved browsing permission through the normal interface; the secure exchange and private snapshot returned HTTP 200. Complete content use and saved-display acceptance remain in progress. No paid purchase, notification activation or outside-host acceptance is established by this checkpoint.
Check the course engine from the owner screen
The prepared owner screen provides Check the course service on an active course-enabled application in Application access. It uses POST /api/connect/checks/pd-engine through the signed-in Abe owner session, current workspace membership and same-origin guard. Once that screen is released, the operator can choose the audience and a check expiry within the next day, tick the explicit approval and select Run course service check. Opening the panel runs nothing. This invokes the existing bounded public-API engine producer inside Abe's server environment; it does not require downloading production credentials.
The request contains only the application ID, actual Abe provider origin, audience, expiry and confirmation. The server derives the actor; API keys, posted identities and submitted observations cannot invoke or establish the check. A successful response identifies the retained engine check and deployed implementation version. It does not approve source use, an embedded interface, usage, origin, funding, personal permission or notifications. A timeout can leave an uncertain write; inspect the retained original before retrying. Do not treat an uncertain response as rollback or a subscriber success.
Verify Abe's registered reference website
Abe's prepared private operator command scripts/services/record-widget-origin.ts checks the ordinary embedded document on Abe's own reference website. It requires the current owner context, the configured reference application and an already accepted embedded-interface original for the exact service and audience. It observes real window messages and Chrome's refusal of an unregistered ancestor, then rechecks the owning records before retaining only the website-origin check. Professional-development search and official-update browsing bind to separate interface originals. Operators supply selectors and confirmation, never a submitted passed report or browser observations. This is an internal operator prerequisite; subscribers and outside developers do not run it. It awaits release and genuine hosted acceptance, creates no funding or personal permission, and does not prove a subscriber connection. After an uncertain write, inspect its exact original before retrying.
Qualify the course usage-limit implementation
The prepared operator command node --import tsx scripts/services/record-usage-check.ts checks the existing course-search allowance owners in disposable databases. Its new receipt format requires the reviewed usage-qualification migration before it can be retained in a live environment. The command does not buy access, allocate a quota or prove that a real subscriber used the widget.
Use these exact flags in order: --operation, --app, --context, --owner, --origin, --app-origin, --audience, --engine, --valid-until, each followed by its value, then --confirm-authentic-engine and --confirm-retain-qualification. Keep the caller-retained operation UUID for reconciliation. The remaining values mean the verified application ID, owner's current workspace UUID, approved owner's user UUID, actual Abe provider origin, registered host-application origin, selected audience, genuine retained engine-check receipt ID and explicit check expiry. For Abe's own reference application, both origins can be Abe's verified origin. For an outside host, keep its registered origin separate from the Abe provider origin; do not register Abe as that host to force a successful check. Do not paste credentials into the command. Operators use the protected server environment; subscribers do not perform this step.
The engine original must be current and belong to the same application and audience. The exact deployed source version and the repository SQL used in the isolated check must match. An unknown or changed version refuses qualification. The observation is explicitly labelled implementation qualification, with liveSubscriberProof:false and a repository-SQL basis. This is ability-to-enforce evidence only; deployed database compatibility and an ordinary funded subscriber journey still require separate acceptance. Keep the operation ID and inspect the retained original after an uncertain response before retrying.
Run the existing direct-web interface check
The operator command node --import tsx scripts/services/record-widget-interface.ts invokes Abe's existing browser witness for /professional-development. It accepts these exact flags in this order, followed by --confirm:
| Flag | Required value |
|---|---|
--operation | A caller-retained operation UUID; keep it for reconciliation. |
--actor | The approved platform owner's user UUID. |
--context | That owner's current workspace UUID. |
--app | The existing verified application ID. |
--origin | Exactly https://www.abeai.com.au, http://localhost:8089 or http://127.0.0.1:8089. |
--environment | production for the Abe HTTPS origin, or local for either local origin. |
--audience | The exact individual, organisation or partner audience. |
--engine-receipt | The independently retained current engine original for those bindings. |
--source-items-file | A local JSON array of existing source-permission selectors, at most 128 KiB and 200 items. |
--valid-until | An explicit valid timestamp within the next day, no later than the engine and source permissions expire. |
Each source selector contains only receiptId, sourceUrl, sourceVersion, policyVersion and representation (link or metadata), taken from genuine current permissions. The file cannot supply observations, approval instructions or course data. The producer independently checks the owner, app, engine and exact source permissions before and after its actual browser run. Use the already approved protected operator environment and installed local Browser Harness with its supported local Chrome endpoint; this command does not configure credentials, start an external-host integration or change service settings. A missing browser prerequisite or missing evidence refuses retention.
The output contains retained proof identity, versions, expiry, counts and hashes, without raw course content or owner identifiers. Preserve the exact widget-web:<operation UUID> identity if a write is uncertain; reconcile that identity rather than inventing a replacement operation. This check establishes only a witnessed direct-web interface original. It cannot supply embedded-interface, usage or origin acceptance. The current public page also lacks a source-use-owned credit display: permissions requiring a visible credit or credit link will refuse this check until that genuine display is implemented. Do not relax the permission or invent attribution to obtain a passed result.
Record the operator's accepted deployment
The Abe operator can submit a confirmed declaration through POST /api/connect/deployments after independently recording genuine service checks. This operation uses the operator's signed-in Abe session and resolved workspace, the existing connection gate and a same-origin request. An application credential or organisation API key cannot use it. The operator must be an approved platform owner with current ownership of that workspace; the request cannot choose a different issuer or workspace.
The body contains only id, appId, origin, environment, interfaceVersion, proofs and confirmed: true. Choose one deployment UUID for that declaration, the existing verified reference application, its exact registered origin and the actual environment/interface version. Each service proof must identify the genuinely recorded engine, permitted source representation, accepted customer interface and enforced usage originals for the same application, environment and audience. The independently recorded origin acceptance must match the exact origin, interface receipt and implementation version. Do not send synthetic test receipts, source-approval instructions, unrecorded declarations marked as passed or another application's originals.
The existing issuer independently checks the registered app, current originals, source permission and origin acceptance before and after retention; the owning database operation validates the app, supplied proof bundle and retained receipt status. Missing, withdrawn, expired or inconsistent evidence refuses acceptance. A body containing apparently passed proofs cannot create the missing originals. The course engine producer records an engine observation only; the direct-web interface producer records web acceptance only. Neither fills missing embedded-interface, usage or origin acceptance. Complete those real checks before using this endpoint for the reference widget.
Retain the returned deployment identity and exact original evidence. A failed or uncertain response can follow a committed record: inspect that exact declaration through the protected operator records before any further mutation, and do not replace it with a fresh UUID to bypass the result. Accepted deployment storage does not issue funding, approve subscriber permission, activate a service or create notifications. Genuine owner terms/allocation and the subscriber's deliberate consent remain separate. This endpoint closes the operator invocation gap; its implementation does not establish a released or completed customer test.
Follow the person's reference application test, then retain the genuine source-backed result, pause, expiry, account-change and disconnect evidence. Test repeated Connect, blocked popup and stale return messages. Pause requires an existing separately authorised active alert; do not create one merely to fill an acceptance row. A host developer substitutes their own verified host identity mapping and encrypted server storage, then repeats acceptance on their own registered origin. Abe-origin component tests do not certify an external integration or a payment lifecycle.
Connect Stripe to Abe
The Abe payment operator first follows Stripe product setup. These are developer configuration requirements, not instructions for a subscriber to supply API keys. The current legacy billing routes and the newer commercial funding contracts are separate implementations; completing the customer journey requires their approved composition, not a direct database insert to make an offer appear.
Keep the integration disabled until the approved sandbox setup and its actual account, price, customer mapping and funding checks are ready. Configure each server variable separately in the intended Abe environment, using the protected secret store. Do not commit values, display keys or put them in browser code.
| Server setting | Required meaning |
|---|---|
ABE_BILLING_ENABLED | Payment route gate. Enable only in the prepared environment after its prerequisites are verified. |
ABE_BILLING_MODE | test for sandbox acceptance; live only for an approved live release. |
ABE_STRIPE_ACCOUNT_ID | Exact account ID returned by Stripe using that environment's credentials. A sandbox account may differ from the live merchant account. |
ABE_STRIPE_SECRET_KEY | Server-only Stripe API credential for that same account and mode, with the permissions required by the existing adapter. |
ABE_STRIPE_WEBHOOK_SECRET | Signing secret for that exact environment's registered webhook endpoint. This is distinct from the API credential. |
ABE_CONNECT_CANONICAL_ORIGIN | Abe's exact approved HTTPS origin, used by the connection and payment return routes. This does not register a host origin. |
ABE_CONNECT_ENABLED | Separate connection gate. Enabling payment alone does not enable or verify the user's app connection. |
ABE_PLATFORM_OWNER_USER_IDS | Verify the existing approved platform operator is in this server-side allow-list. The reconciliation route also requires that person's authenticated Abe session and current ownership of the selected context. An absent list permits no operator. This instruction does not authorise adding another platform owner. |
The existing Stripe adapter is pinned to API version 2025-07-30.basil. Verify compatible event and retrieval behaviour in the sandbox rather than upgrading it as a setup shortcut. Read back configuration names, mode and account safely; never print secrets.
Register a signed webhook endpoint at the prepared Abe HTTPS origin plus /api/connect/billing/webhook. Select account events for that merchant, not connected-account events or a different sandbox. Stripe's webhook guide describes endpoint registration and signature verification. The current Abe event processor handles:
checkout.session.completedandcheckout.session.async_payment_succeeded.customer.subscription.created,customer.subscription.updatedandcustomer.subscription.deleted.invoice.paidandinvoice.payment_failed.charge.refunded,charge.dispute.createdandcharge.dispute.closed.
The webhook verifies the raw signed request and retains the event before acknowledgement. An acknowledged event is not confirmed funding. Current processing uses the protected owner-confirmed POST /api/connect/billing/reconcile operation; the webhook does not run the payment-to-access reconciliation itself. There is no accepted unattended payment processor established by these setup instructions. Complete and test processing, pending-event recovery and current-state read-back before selling an automated subscription. Do not create an additional cron or give a worker an owner's browser session to bypass this requirement.
Bind the verified processor customer to the intended Abe account through the approved purchase workflow. Do not match customers by email or let client-supplied Stripe metadata select the beneficiary. Match the actual recurring price, amount, AUD currency, interval, explicit tax behaviour, account and mode to the approved offer. Retain independent source permissions, usage limits, funding origin and the person's consent. An owner's non-priced allocation must never count as a settled processor purchase.
Configure the sandbox customer portal using Stripe's portal guide. Do not enable unsupported quantity, plan, discount or proration changes. Prove each supported change updates Abe correctly and preserves independent access. The current full downgrade and cancellation acceptance remains outstanding.
The release record needs actual purchase, failed payment, renewal, delayed and duplicate events, refund or dispute, downgrade, cancellation and access read-back. It must also show no notification activation merely from payment. Only after those checks and owner approval may live prices, credentials, webhook configuration and the exact live account be activated. Sandbox success does not prove live configuration.
What success looks like
An approved test proves the exact application, origin, person, organisation, permission and source-backed result. It also proves refusal, expiry, revocation and switching to another account without data crossover. A configuration entry, tool list, payment or successful HTTP response alone is not customer acceptance.
Existing read access does not supply extended policy generation, task creation or assessment rights. Those require a separately accepted action interface and explicit permissions. Organisation governance stays in its authorised organisation; personal access is not an organisation document licence. Use Governance and readiness for current assurance limitations.
If it does not work
Stop on wrong identity, organisation, origin, scope or revision. A provider-unavailable response is a gate, not an invitation to use an organisation service key as the person. Respect rate-limit timing, and do not blindly retry an uncertain write or send. Ask support with the route, approximate time and safe error; omit credentials, private criteria and patient information.
Stop or change your choices
Let the person disconnect the intended application in Application permissions. The host should stop locally before reconciling remote revocation; a pending remote result stays pending. Verify old delegation can no longer access protected operations, including after funding expires. Preserve saved choices and manage billing separately. See Manage and cancel.