Use the signed-in user

Who is asking, how the copilot reaches your API as them, and what happens when they sign out or switch accounts.

Three different things identify something in Rendel, and only one of them is anybody's permission to do anything.

	What it is	What it proves
App key (`rd_pk_…`)	Ships in your app or page. Names your app and its environment (test or live).	Nothing about the person. Anyone with your app has it.
`identify`	The id of the person signed in to your app, from your own sign-in.	Who the conversation belongs to: their history, their memory, the person a confirmation was shown to. With identity verification on, an HMAC from your backend proves it.
User token	The signed-in person's own token for your API, from your auth library.	Whatever your API decides it proves. Your API checks it, as it does for your own app.

Pass all three

Flutter

// At startup
await Rendel.init(
  appKey: 'rd_pk_live_…',
  config: RendelConfig(
    // Asked for before every question, so return the current one.
    userToken: () async => auth.currentAccessToken(), // null when signed out
  ),
);

// Right after your sign-in succeeds
await Rendel.identify(userId: user.id, userHmac: user.neonHmac);

// On sign-out
Rendel.reset();

Web

Rendel.setUserToken(() => auth.currentAccessToken()); // null when signed out
Rendel.identify({ userId: user.id, userHmac: user.neonHmac });

// On sign-out
Rendel.reset();

userHmac is optional. Turn identity verification on in the console (Settings → Security) and have your backend sign the user id with the secret it gives you; from then on an id without a valid signature is treated as nobody.

When the token reaches us, and when it does not

Actions registered in your app run in your app, with your app's own session. The token never needs to leave the phone or the page.
Actions connected in the console and set to the signed-in user's token are called by our server, with the token your app hands over on that question, as Authorization: Bearer. It is used for that call and dropped. It is never stored, logged, shown in the console, or put in front of the model.
Any other console action uses a key you stored, an account made for the copilot, or nothing. Those may only read.

When it is asked for

Before every question. Return the current token: if your auth library refreshed it in the meantime, the new one is used. Return null when nobody is signed in. A provider that throws costs that question the token, not the answer.

What changes something, and for whom

A console action that changes something (a POST, PUT, PATCH or DELETE you marked as such) needs all of this:

It runs as the signed-in user. The database refuses any other kind of credential for it.
The turn names the person with identify (proved by HMAC if you verify identities). With nobody named, it is not offered.
The user confirms it on the card, and the server records that tap for the device that owns the conversation.
The request that continues after the tap names the same person. A token refreshed for them is fine. Somebody else signed in on the same phone is not: the change is not made, and the copilot asks again.

The server then calls your endpoint once, however often the continuation is retried. If the answer is lost on the way back, the copilot says it does not know whether the change happened instead of trying again. See Actions from the console.

Sign-out and switching accounts

reset() clears the thread on the device, the person, and any card still on screen; the next question is anonymous until the next identify. Calling identify with a different id does the same for the thread. If your app switches accounts without calling either, the server still will not spend one person's confirmation on the next person's token (rule 4 above), but the old thread stays on screen, so call reset() on sign-out.

401 and 403

401 from your endpoint, for a console action called as the user: the person's session has most likely ended. The copilot says so, and the call is not repeated. Your app's next token, from your own refresh, is used on the next question.
403: your API said this person may not do this. The copilot tells them it cannot be done here. Nothing retries it.

Testing with a real account

The console's Test page has no way to sign in as one of your users, so a console action set to the signed-in user's token answers "not signed in" there. Test it from a build of your app, signed in as a test user, and pair it with the console to watch the conversation from the Test page. examples/web-market in the repository is a minimal web host that does exactly that against a demo API.

Who enforces permissions

Your API. The copilot can reach only the actions you connected, only as the person asking, and only after they confirm anything that changes something; what that person is allowed to change is your API's decision, exactly as it is for your own app.

Use the signed-in user

On this page