Peerlogic Technologies
Our engineers inside Peerlogic's team turn raw phone events into trusted call records
Peerlogic's call intelligence platform for dental and vet practices needs every call from each phone system as a reliable record. Our engineers work inside its team, in its repositories and cloud under its CTO's review, and proved each provider's events with real calls first.
Healthcare & WellnessPractice call intelligence SaaSModernized a live product
- Built
- Webhook intake, validation and call record transform
- Phone providers
- GoTo Connect, Jive, Netsapiens, Bandwidth
- Built in
- Peerlogic's own Google Cloud environment
- Shipped through
- Peerlogic's pull request review
The challenge
Peerlogic's call summaries and follow-up depend on capturing every call, but each phone provider exposes call events differently, and the first provider changed its call events API during the work.
What we did
Inside Peerlogic's team, we tested both subscription models with real calls, then built webhook intake, validated event models and a cloud function that writes the call records.
The outcome
The intake path shipped through Peerlogic's own pull request review, its API client went out as two pre-releases and a final release, and Peerlogic has kept our engineers in its team since.
The starting point
Peerlogic is an established, live platform that helps dental and veterinary practices understand their calls, follow up and book appointments. It had its own engineering team, its own API, a published API client package and a cloud function pipeline, and it integrated with many practice management systems and phone providers.
What had to change
Call summaries, missed opportunity detection and follow-up all depend on capturing every call from each practice's phone system. Each provider exposes call events differently, so each needed its own path into the same call records.
What could not break
- All work fits the product's existing API, published API client and cloud function pipeline
- Every change passes Peerlogic's pull request review before release
- Changes to the published API client cannot break the product around it
- Practice data stays inside HIPAA-aligned boundaries and the existing permission model
The calls we made
We treated call data as the foundation Peerlogic's AI stands on, so our engineers learned the product from the inside and proved the provider's events with real calls before building the intake.
- 01
Learn the product before adding to it
Onboarding inside Peerlogic's team started with the product's data model, its audio pipeline and the code of its existing phone integration, along with captured call events and call flows from that integration.
Ruled outBuilding a new integration before knowing how the existing one captured calls.
- 02
Test both subscription models side by side
Account level and line level subscriptions behaved differently, so we placed real test calls and compared both event streams before building on either, and tested again when the provider changed its call events API.
Ruled outPicking a subscription model from the vendor's documentation alone.
- 03
Validate every event
Raw events differ by provider and by subscription, so serializers and typed Pydantic models check each event extract before the cloud function turns it into a call record.
Ruled outPassing raw provider events straight into the product's call records.
- 04
Release the API client in stages
The integration changed Peerlogic's published API package, so the changes went out as two pre-releases with Pytest coverage, tested against the cloud function, before the final release.
Ruled outOne release of the published package straight to production.
How the system fits together
What we built
Provider integration app
A Django integration app with OAuth and an auth backend for the phone provider, capturing call events by webhook for both account level and line level subscriptions.
Validated event extracts
Serializer validations and Pydantic models for the event extracts, plus Django viewsets for event extracts and API credentials, each with tests.
Event to call record transform
A Google Cloud Function that creates or updates the product's call and call-partial records from raw events, refactored to accept both HTTP and Pub/Sub payloads.
API client releases
The integration added to Peerlogic's published API package with Pytest coverage, shipped as two pre-releases and then a final release.
Recordings and further providers
Bandwidth API setup with an API client and cloud function for call recording retrieval, a review of the first provider's Reports and Recordings APIs, and analysis of another provider's audio flow.
How it works
Call
A call is placed or received on the practice's own phone system.
Event
The provider sends call events by webhook through the authorized integration.
Validate
Serializers and typed models check each event extract before it moves on.
Record
A cloud function turns the events into the product's call and call-partial records through the API client.
Use
The product's call summaries, follow-up and analytics work from those records.
A closer look
What changed
The intake path for the first provider shipped through Peerlogic's own review: webhook intake, validated event extracts, viewsets with tests, the transform cloud function and a staged API client release. Recording retrieval for a second provider followed, and Peerlogic has renewed the engagement.
Under the hood
- Datics role
- Forward deployed engineering
- Integrations
- GoTo Connect call events, with its Reports and Recordings APIs reviewed, plus work on Jive, Netsapiens and Bandwidth.
- Data boundary
- Work stays inside the product's existing permission model, with practice data handled within HIPAA-aligned boundaries. Peerlogic owns the code and its IP.
- Deployment
- Google Cloud Functions and Pub/Sub in Peerlogic's own Google Cloud environment, with Django REST viewsets in the product's API.
- Testing
- Pytest coverage for the API client, tests for the new viewsets and test cycles of the cloud function against Peerlogic's API package.
Apps and APIs
Also in the stack
How it shipped
Onboarding and study
We joined Peerlogic's engineering team and studied its data model, audio pipeline and existing phone integration, capturing that integration's call events and call flows.
Prove the events
For the new provider, we compared account level and line level subscriptions with real test calls, configured line subscriptions through its OAuth client, and tested again after it changed its call events API.
Intake path
Viewsets with tests, validated event extracts and the transform cloud function followed, with the API client released in stages and pull request changes requested by Peerlogic's CTO resolved.
Recordings and more providers
Bandwidth recording retrieval, a review of the first provider's Reports and Recordings APIs and an analysis of another provider's audio flow came next.
Scope set with Peerlogic's CTO
We set the first scope with Peerlogic's CTO: backend integration with a phone provider's API, and the screens that help a new customer connect their phone system.
Inside their repositories and review
Our engineers worked in Peerlogic's own repositories and cloud, and every change went through its pull requests and its CTO's review before release. Peerlogic owns all of the code.
With the vendor's support team
When the provider's API changed or its documentation fell short, we worked through it with the vendor's support team, including a detailed support ticket, before building on it.
What this unlocked
The validated call intake gives Peerlogic's AI features a dependable base, and our engineers continue to work inside its team.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.