Partner developer kit
For developers at a site with profile pages (a directory of professionals, studios or small businesses) who are adding the platform's messenger. Start here on your first day.
What the platform does for your site
Visitors write to the profiles on your site from a messenger on your pages. Each profile's owner answers in an inbox inside your own owner dashboard. When the owner is away, an AI assistant can reply for them, from the profile data you send and under a label that says it is an AI assistant. Your site stays the source of truth: your backend sends the platform a copy of each profile, and the platform never calls your site to fetch one.
The pieces
| Piece | What it is | Who works on it |
|---|---|---|
| The partner console | Where your team gets keys, lists allowed origins, watches the profile sync and shapes the AI assistant | Your developers and admins |
| The messenger | The chat on your profile pages: a launcher and a frame from the loader script, or the mp-messenger element in your own layout |
Frontend |
| User tokens | Short tokens your backend signs, so a user signed in on your site is signed in to the messenger and the inbox too | Backend |
| Profile sync | Your backend sends each profile, keeps it current, and deletes it when it goes | Backend |
| The owner inbox | A frame in your owner dashboard where owners answer their visitors | Frontend and backend |
| The AI assistant | Replies for owners from public and AI-only profile fields, your playbook and the owner's instructions | Admins, in the console |
Which credential goes where
| Credential | Where it goes |
|---|---|
Publishable key, pk_... |
Your pages. It is public |
Secret key, sk_... |
Your backend only, for profile sync. Never in a browser, an app, a repository or a log |
| Token signing key | Your backend only: the private key that signs user tokens. You upload only its public half |
| User token | Made by your backend for each request, passed by your page to the messenger. Never logged |
Guide 1 explains each one.
The path to go-live
Work through the guides in this order. Everything happens in your sandbox site until go-live.
- Keys and allowed origins: sign in to the partner console, copy the publishable key, make the secret key, upload your token signing key, and list your pages' origins.
- The profile lifecycle: send your profiles, keep them current, and know what each field feeds: the profile's card, the AI assistant, or nothing. The messenger shows a profile only once it has arrived, so send profiles before you add the messenger.
- The messenger on your profile pages: add the loader and a "Message" button that opens a profile's chat, or the
mp-messengerelement. - Signing visitors in: a token route on your backend, and
getUserTokenon your page. - The owner inbox in your dashboard: serve the dashboard on an origin of its own, frame the inbox there, and sign the owner in.
- The AI playbook, sync health and going live: shape the AI assistant, watch the sync, and get ready for go-live, which is not open yet.
Examples and reference
- examples/node/ holds runnable Node programs with nothing to install: signing user tokens, the two token routes on your site's server and your owner dashboard's, and the whole profile lifecycle against your sandbox site.
- reference/ holds the routes your backend calls in two forms, both made from the platform's API document, so they match the code. server-api.md is the page to read, with every field, error and example. openapi.json holds the same routes as an OpenAPI 3.1 document, for your tools, such as a client generator.
- The contracts are the exact rules the guides teach from, and each guide links the sections it relies on: profile sync, user tokens, the messenger loader, the
mp-messengerelement and the inbox in your dashboard.
The contracts are also the platform team's working documents. Skip what is there for that team: source paths such as api/openapi.json, requirement and decision numbers such as A-4, D-73 or INV-3, and, in the repository, the "Open points" sections and change logs.
Coming later
Webhooks, such as needs_owner when a conversation needs the profile owner, going live, and paid messages come in later releases. So does signing in to your site with an account on the platform, for people who have one. None has a shape you can build against yet.