Documentation
Reference for the TMJ Journey APIs. Written for whoever maintains the website or the integration — it explains the API and sells nothing.
APIs
Lead Intake API
Post a lead from a contact form you already built — Webflow, WordPress, Squarespace, hand-written HTML — straight into the practice's TMJ Journey inbox. Send the body your form already produces; field names are matched for you.
POST /api/intake/v1/leads- Browser key or server token
- Writes one lead
Lead Intake demo
Try a contact form, an appointment request, a TMJ pain quiz and a sleep quiz, and see the request each one sends, what comes back, and what the practice sees. Nothing you type is sent.
- Contact, appointment, pain and sleep forms
- Request, reply, inbox and chart
- Runs entirely in your browser
Publisher API
For programs that author content and offer it to practices. Read what your program published and how many practices took it up, without opening the console.
GET …/publisher/activityGET …/publisher/adoption- Read-only, no patient data
Hosted web forms
Not an API. If you would rather TMJ Journey hosted the form than integrate one, build it at Marketing → Web forms inside the app and embed the snippet it gives you — no key, no code, submissions land in the same inbox.
Use the Lead Intake API when the form already exists and nobody wants to rebuild it.
Conventions
The same across both APIs
| Lead Intake API | Publisher API | |
|---|---|---|
| Host | The practice's own domain | tmjjourney.com |
| Credential | pk_live_… publishable, or a sa_… service account token |
pub_… bearer token |
| Safe in page source? | The publishable key only, and only from an allowed origin | No — server-side only |
| Direction | Write one lead | Read, never write |
| Where you get it | Marketing → Leads, inside the app | Publisher → Account → API tokens |
Everything else
- JSON in, JSON out. Errors are
{ "error": "..." }with a meaningful status code. - Keys are shown once. We store a hash, so a lost credential is replaced rather than recovered — and revoking one takes effect immediately.
- Everything is rate limited, and the limit is stated in the response headers rather than left for you to discover by being blocked.
- No patient data crosses either API. One writes an enquiry that has not yet become a patient; the other reads publishing metadata. Clinical records move through the app, under a BAA.
Developers
Building against TMJ Journey?
Tell us what you are trying to do. It reaches the people who wrote the endpoint, not a support tier.