Connecting a product’s sign-in
For the developer at a company that puts its product in AI apps with Zest.
When a person adds the product to their AI app (ChatGPT, Claude, Copilot, Codex), the AI app asks them to sign in. They sign in on a page in your brand, with your logo and colors, and never see Zest. Zest then keeps a token for that person and sends each of their calls to the product API with it, so every call is made as them, with their permissions, and shows up in your logs as them. That is all Zest does with sign-in: it keeps one token per person, never a password, and it creates no accounts in your product.
You pick one of four ways on Connect, under “How your people sign in”. Each one below says what we need from you and what happens when a person signs in. Until “Calls go to” the product is on in Connect, every way signs in with a sign-in code and nothing is sent to the product, a password included.
1. Your sign-in service (OAuth)
The one to pick if you have it. Your product runs an OAuth 2.0 authorization server with the authorization code flow, the same one behind any “Sign in with …” button.
What we need from you
| Field | What it is | Example |
|---|---|---|
| Authorization URL | Where a person signs in and approves | https://app.yourproduct.com/oauth/authorize |
| Token URL | Where a code is traded for a token | https://app.yourproduct.com/oauth/token |
| Client id | An OAuth app you create for Zest | zest-prod |
| Client secret | That app’s secret. Pasted once, never shown again | |
| Scopes | What the product API needs, space separated | read write |
Also allow Zest’s return address as a redirect URI on that OAuth app. Connect shows it under the OAuth fields; it ends in /oauth/product-callback.
What happens at sign-in
The person types their product email on your branded page, then is sent to your authorization URL and signs in where they always do, with your two-factor or single sign-on if you have them. You send them back with a code. Zest trades the code for their access token (and refresh token, if you issue one) at your token URL, keeps it for that person, and calls the product API with it.
2. Your login endpoint
For a product API with an endpoint that takes an email (or username) and a password and answers with a token the rest of the API accepts.
What we need from you
| Field | What it is | Example |
|---|---|---|
| Method and path | The login endpoint on the product API | POST /auth/login |
| Email field name | The field that carries the email or username | email |
| Password field name | The field that carries the password | password |
| Token path | Where the token is in the reply | data.token |
| Role field (optional) | Where the person’s role is in the reply | user.role |
| Role map (optional) | Which value of that field is which role | therapist → Clinician |
The endpoint takes POST, PUT or PATCH with a JSON body. GET is not supported: it would put the password in the URL, where servers and proxies log it.
What happens at sign-in
The person types their product email and password on your branded page. Zest calls your login endpoint once, reads the token from the path you gave, keeps the token for that person and drops the password as soon as the call returns. With a role field, the person gets the role the map says; without one, a new person starts in the first role and the product manager can change it in Zest. Two-factor is not supported in this mode; if your login can ask for a second step, use OAuth.
3. A token each person pastes
For products that give each person their own API token (a personal access token).
What we need from you
| Field | What it is | Example |
|---|---|---|
| Where to get the token | The page in your product where a person makes or copies their token. We link to it on the sign-in page | https://app.yourproduct.com/settings/api |
What happens at sign-in
The person types their product email and pastes their token on your branded page. Zest checks it with one read from the product API, keeps it for that person, and calls the product API with it. When it stops working, they paste a new one.
4. One shared key
For demos and testing only. Every person is the same account.
What we need from you
| Field | What it is | Example |
|---|---|---|
| API key | One key for the product API, pasted once on Connect |
What happens at sign-in
Each person types a one-use sign-in code the product manager gives them from Publish, and every call goes to the product API with the same key. The product API cannot tell people apart, so do not use it with real people’s data. Once any other mode is saved, this one is hidden.
Security rules
- A token per person. Every call is made with the token of the person who asked, with their permissions. One person’s token is never used for another.
- Never a password. In login mode the password goes to your login endpoint once, over HTTPS, and is not stored or logged. In every other mode Zest never sees it.
- Tokens stay out of sight. They are stored apart from everything else and never shown: not on the dashboard, not in the AI app, not in Activity.
- Removed means revoked. When a person is removed in Zest, their token is deleted at once. You can also revoke it on your side at any time; the person then signs in again.
- HTTPS only. Every address you give us starts with https://. Zest calls nothing else.
- Nothing else is kept. The token, its refresh token and expiry when you issue them, and the person’s role. The client secret or shared key is saved once and never shown again.
A product manager can also let one person in with a sign-in code from Publish (15 minutes, one use), in any mode. It is for support, not a second login.
Which one fits
| If the product… | Use |
|---|---|
| has an OAuth server, or “Sign in with …” for other apps | Your sign-in service (OAuth) |
| has a login endpoint that returns a token the API accepts | Your login endpoint |
| lets each person make their own API token | A token each person pastes |
| has one API key for the whole account | One shared key, for a demo, then tell us |
| none of these, or you are not sure | Tell us at hello@limeadelabs.com and we set it up with you |
Ask your AI to check
Paste this into Claude Code or ChatGPT with the product’s API spec or codebase open:
Read this API/codebase and tell me which of these four sign-in modes fits, and give me the exact values: 1. OAuth (authorization code flow): the authorization URL, the token URL, where to create an OAuth app to get a client id and client secret, the scopes the API needs, and whether refresh tokens are issued. 2. Login endpoint: the method (POST, PUT or PATCH, with a JSON body) and path of the endpoint that takes an email (or username) and password, the email field name, the password field name, the path to the token in the reply (like data.token), the path to the person's role in the reply (optional, like user.role) and every value it can have, and whether the login can ask for a second factor. 3. Personal API token: whether each person can create their own API token, and the URL of the page where they do it. 4. One shared key: only if none of the above exist. Also tell me the header the API reads the token from (Authorization: Bearer, or another), whether every URL is HTTPS, and anything that would stop a token working for a server that calls the API on the person's behalf (IP allowlists, very short expiry, device binding). Answer with the mode you recommend, the values as a list I can paste into a form, and any question I should ask the product team.
Questions, or a sign-in that fits none of these: hello@limeadelabs.com