A Thirdlane customer portal integration should start with a product decision: which tasks belong in your customer account experience, and which should remain in Thirdlane? Its native User Portal already covers personal telephony settings, voicemail and recent calls, subject to administrator permissions. A custom portal should therefore target specific gaps rather than recreate every screen. This guide explains how to verify the available interfaces, expose useful self-service operations and launch without treating documentation examples as universal contracts. ([thirdlane.com](https://www.thirdlane.com/platform-docs/user-portal/thirdlane-user-portal/))
1. Define what the customer portal should actually own
Separate three experiences in the requirements: your commercial customer account, Thirdlane’s personal User Portal and tenant administration. The native User Portal supports forwarding, screening, blocking, voicemail and recent calls; its visible controls depend on User Extension permissions. Thirdlane Connect also provides many of these features. Use that overlap to decide where links and native workflows are sufficient, rather than automatically commissioning replacement interfaces. ([thirdlane.com](https://www.thirdlane.com/platform-docs/user-portal/thirdlane-user-portal/))
For a first release, consider a service summary, an authorized call-history view and one controlled administrative change, such as updating an extension’s display information. Keep invoices, subscriptions and support tickets with their existing systems of record unless there is a separate reason to move them. Define each proposed screen by its data owner, audience, permitted action and acceptable age of data.
Distinguish navigation integration from functional integration. A link to Thirdlane is not shared authentication; matching colors is not embedded functionality. Thirdlane documents persistent customization of the User Portal Welcome page through language-specific files, but that does not establish a general-purpose embeddable portal SDK. If embedding is a requirement, test browser framing, cookies and navigation explicitly before promising it to customers. ([thirdlane.com](https://www.thirdlane.com/platform-docs/user-portal/thirdlane-user-portal/))
2. Establish a release-specific API contract
Record the deployed product or edition, server release, enabled features and account permissions before estimating scope. As of October 29, 2026, Thirdlane’s public release notes identify version 16.2.1, released September 16, 2026, as the latest platform release. They describe new reporting APIs, service-plane discovery and tenant-bound API keys. Do not assume an older deployment offers those capabilities simply because current documentation describes them. ([thirdlane.com](https://www.thirdlane.com/platform-docs/whats-new/))
Open Tools > OpenAPI REST in the target installation, or inspect `/apitest/openapi/`. Download the installation’s merged specification from `/apitest/openapi/thirdlane-api.yaml` and retain it with your integration tests. There is a concrete reason to verify paths: the configuration guide shows extension examples under `/api/tenants/{tenant}/extensions/`, while the endpoint index describes `/api/extensions/{tenant}`. The installed contract, not a guessed naming convention, should determine your requests. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/tools/api/))
Build a capability checklist for every intended operation: endpoint, method, required fields, response schema, privilege and tested release. Thirdlane’s API Basics distinguishes tenant-scoped multi-tenant requests from single-tenant systems, which omit tenant scoping. Confirm licensing and feature availability separately with the deployment owner or vendor; an endpoint appearing in public documentation is not proof that every edition, entitlement or older build supports the complete workflow. ([thirdlane.com](https://www.thirdlane.com/platform-docs/developers/api-basics/))
Let's map the integration before complexity grows.
Tell us which platforms need to connect. We'll help turn the workflow into a clear, reliable implementation plan.
Talk to iMingos ↗3. Separate customer login from PBX authorization
Use a portal backend to make Thirdlane requests rather than exposing an administrative credential to browser code. Current documentation recommends the `X-API-Key` header and supports tenant-bound keys. Keys inherit their creating administrator’s scope and do not expire automatically. Prefer a named, appropriately restricted owner, separate integration credentials and a documented rotation process; verify those controls on the deployed release. ([thirdlane.com](https://www.thirdlane.com/platform-docs/developers/api-basics/))
At the portal boundary, resolve the authenticated customer to an approved Thirdlane deployment, tenant and allowed resources. Do not accept a browser-supplied tenant name as authorization. For example, a personal call-history request should resolve to the current user’s permitted extension, while a customer administrator’s request may cover an approved organization. Apply this check to exports and recording downloads as well as ordinary pages.
Treat SSO as a separate implementation track. Thirdlane documents OIDC authentication for Configuration Manager and Thirdlane Connect, with MFA handled by the identity provider. Its documented flow requires existing PBX accounts; SSO does not create them automatically. This does not establish that an arbitrary custom customer portal can exchange its session for a Thirdlane session. Validate the exact application, callback URLs, account mapping, logout and fallback-password behavior. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/system-settings/sso-mfa-authentik/))
4. Implement reporting and configuration as different workflows
Begin with read-only reporting. Thirdlane documents historical CDR, MDR and recorded-call APIs with time-range filtering and pagination. For example, its current CDR documentation uses `/api/reports/cdr/acme`, supports filters such as source, destination and disposition, and includes a `has_recording` flag. Require bounded date ranges in your portal, translate customer-local dates into explicit timestamps and make exports separate, authorized operations. ([thirdlane.com](https://www.thirdlane.com/platform-docs/developers/reporting/))
Treat audio access separately from call metadata. The reporting guide states that recording entries include an absolute `download_url`, fetched with the same authentication. A recommended portal design is to reauthorize the user at download time and retrieve media through a controlled backend, without sending a reusable PBX credential to the browser. Avoid logging audio URLs, credentials or complete sensitive responses, and define how expired or deleted recordings appear. ([thirdlane.com](https://www.thirdlane.com/platform-docs/developers/reporting/))
For configuration changes, expose a small field allowlist instead of forwarding arbitrary JSON. Read the current object, validate the proposed change, submit only permitted fields and read back the result. Keep a portal audit entry with actor, target, requested values and outcome. Release-specific tests matter: the 16.2.1 notes describe fixes to omitted-field updates, queue-agent persistence and routing conditions. Never infer safe update behavior across older releases from the newest documentation. ([thirdlane.com](https://www.thirdlane.com/platform-docs/whats-new/))
5. Make freshness and failure behavior part of acceptance
Where supported, use webhooks to invalidate portal caches after relevant changes. Thirdlane distinguishes tenant webhooks from system webhooks: system subscriptions cover a focused set of extension, DID, trunk and tenant lifecycle events, not every tenant-internal event. Signing is available when a secret is configured. Match the subscription to the needed event coverage, verify signatures and retain a scheduled refresh path rather than assuming webhook delivery alone guarantees current state. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/system-settings/system-outbound-webhooks/))
Design uncertain outcomes before launch. If an update times out, show that its result is unconfirmed and read the object before retrying. Do not blindly repeat creation requests. Test authorization denial, missing resources, expired credentials, malformed input, unavailable media and an unavailable PBX. Show a last-updated timestamp for cached views; disable writes when authorization or target resolution cannot be established.
Release in stages: read-only access, one reversible change, then broader administration after operational review. Acceptance should include cross-account access tests, credential revocation, recording authorization, read-back verification and an upgrade rehearsal against the next specification. For iMingos, the practical framing is to make each customer action traceable from portal permission to verified Thirdlane behavior—not to reproduce the entire PBX administration interface.
Frequently asked questions
Do we need to replace Thirdlane’s native User Portal?
Not necessarily. It already provides personal telephony settings, voicemail and call-history functions. Assess those workflows first, then build custom screens only where your customer account experience has a defined gap. ([thirdlane.com](https://www.thirdlane.com/platform-docs/user-portal/thirdlane-user-portal/))
Can we use identical requests across Thirdlane deployments?
Do not assume so. Verify the installed OpenAPI reference, tenant-scoping rules and release behavior. Maintain a tested capability profile for each supported deployment rather than relying on one public example. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/tools/api/))
Does Thirdlane SSO automatically provision customer users?
No. The documented OIDC flow requires existing PBX accounts and does not automatically create them. Plan provisioning separately, and test authentication for the specific Thirdlane application you intend to launch. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/system-settings/sso-mfa-authentik/))
Can system webhooks keep every portal screen current?
No. Their documented coverage is a focused lifecycle subset. Tenant-internal events require appropriate tenant subscriptions where supported. Use events to trigger refreshes and retain a recovery mechanism for stale portal data. ([thirdlane.com](https://www.thirdlane.com/platform-docs/configuration/system-settings/system-outbound-webhooks/))