Hi, regarding the email about the webhook change

"We want to let you know about an important upcoming change to the User Management Element when used with webhook-only configuration (i.e., without email settings).

[...]

Starting in 14 days:

This behavior will change. Instead of immediately creating the user, the webhook will now send an "invitation" event, and the user will only be created once the invitation is accepted.

Can we test this behavior in our environment first to see if everything is working as expected ?

Hi @Robin Simard, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hey @Robin Simard, right now this behavior works only if both email and webhook notifications are enabled. You can set up an email (just for testing) and try the webhook. In 14 days, webhook-only notifications will be in production.

Ok, so we have to handle the invite_user webhook, but the pending invite status and new Element iframe will come later and not after 14 days, right? We use the webhook to create the user in our platform and send them a welcome email with a temporary password.

The pending invite status is already exists when both email and web notifications are enabled. In 14 days, the pending invite status will be visible also when the webhook only is enabled

So if I understand correctly, in 14 days we won’t be able to skip the pending status or the email sent by Permit? And adding a tenant to Permit will only happen once the invited user accepts the invitation?

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

The first image shows our current flow

We have this behaviour when testing:

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

so we need now to implement this: https://docs.permit.io/embeddable-uis/email-configuration-and-templates/#2-approving-the-invited-user-using-an-sdk

Correct, the approval call is the added requirement.

this function does not seem to exist: https://github.com/permitio/permit-python/blob/main/permit/api/users.py to do this:

await permit.api.users.approve(
    user_key="new_user",
    email="new-user@example.com",
    invite_code="ed32bc43e2194a80a5ef5e0339943b44"
)

Thank you. Let me be honest. This is a very short notice to apply a fix in production in less than two weeks on our end. Especially if its not possible to do it.

How long would you like?

i’d say 1 month from the moment it is available from the python SDK. the onboarding process is crucial and it needs to be tested properly. The email states it is just to fix the webhook. but in reality its not the case, a lot of new things is going on in the new flow:

You got it 🙂

before:

Reading your images here - from the diff it seems like you have removed the webhook, and have replaced it with the email flow - that is not a requirement - you can continue to work with the webhook

the email states:

If you’re using this feature, please review your implementation and ensure your webhook handler is ready to support this new flow.

we go to the doc: https://docs.permit.io/embeddable-uis/webhooks/ the doc:

Happy to answer any questions and clarify, as well as learn and improve ourselves and our docs. Thank you for your patience. Note the docs, don’t say anything about having to use the email feature

so to test the behavior, we check “email notification” on our end as well. and we get a totally different behaviour

What behavior are you getting ? And what behavior did you expect ?

is says there it will behave like Email Notification

Soon (After the 14 days) - it will behave like the email feature, meaning the user will only be created after approval

I think what he meant, is that if you wan to test the approval flow of user creation today you can try the email flow instead of the webhook flow

we just want to validate now if the webhook will work with the new behaviour of the webhook.

You can add the approve call now, it will have no effect; And when the new webhook-flow is enabled it will take effect. For testing using the approve function with an effect now, you can use the email flow. In the end of the day it’s the same logic- 1. User is invited and pending 2. User accepts invite - and approve it 3. User is created

do you have any sequence diagram that explains the flow? here’s this one as reference:

sequenceDiagram
    title: Permit Current Invitation Behaviour
    
    App ->> Permit: Invite user

    Permit ->> Permit: Create permit user    

    Permit ->> App: Webhook: "create_user"

    App ->> User: Send user invitation

I can see some issues with skipping the approval One I can see is when a user sends an invitation and sees the pending invites in the interface. This will cause confusion on our customers, since there will be a delay between the time the user sends an invite and when the webhook is triggered to approve him

Here you go, I tried to be very detailed

So Permit will not send any email to the user?

there will be a delay between the time the user sends an invite and when the webhook is triggered to approve him

1. The webhook delay should be very small. 2. There is more delay until the invite is actually accepted - but this is how invites work in most applications

Webhook: User invite was created

what is the “type” we receive?

I’m sorry, can you explain the question - I”m not sure what you’re asking Type of what?

webhook communicates with payloads

Yes “invite_user”

thanks for the clarifications. i’ll analyse your schema with my colleague tomorrow.

Happy to try and help 🙂 Thank you for your patience

We won’t have to call “accept” of the python SDK if I understand well.

Once it’s added you can call it to approve the invite. You can also call the API directly, whichever you prefer

a checkbox somewhere “test new invitation behaviour” would have been great.

You don’t have a token (that’s just in email) , instead you have your webhook secret so you know it’s trustworthy

we weren’t sure if each element invitations had to be accepted separately using the token

In email yes. The token is used to couple between a user (once logged in to the element) and its invite Different purpose than in the webhook In both flows you need to accept each invite.

then make sure the “accept” sdk update is ready soon. that would be really appreciated.

It will be available in the webhook, once the change is applied

i did not find this information in the doc

Hi @Jules Robichaud-Gagnon We added this to the system (invite_id in webhook) and also the approve for Python SDK. It will be released for production tomorrow. We will update you on that.

Thanks, we will test this very soon. I am glad you started to use mermaid diagrams. You need to update your documentation (https://docs.permit.io/embeddable-uis/email-configuration-and-templates/#2-approving-the-invited-user-using-an-sdk), “approve” was added to a different module.

users

-->

user_invites

This:

await permit.api.users.approve(
    user_key="new_user",
    email="<mailto:new-user@example.com|new-user@example.com>",
    invite_code="ed32bc43e2194a80a5ef5e0339943b44"
)

should be:

await permit.api.user_invites.approve(
    user_key="new_user",
    email="<mailto:new-user@example.com|new-user@example.com>",
    invite_code="ed32bc43e2194a80a5ef5e0339943b44"
)

The code: https://github.com/permitio/permit-python/blob/main/permit/api/user_invites.py

Thank you💪, we will also update the documents in the link you sent soon.

https://github.com/permitio/permit-python/pull/119 user_invites was not added to the SyncClient. I created a PR to fix this.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

no

Hi @Jules Robichaud-Gagnon I’ll let @Shuvy Ankor know about it, though he’ll probably only see it next week

Hi, @Jules Robichaud-Gagnon thank you very much! We will look into this as soon as possible.

we have two environments why in one element of one of our environment we see the pending invitations? We do not have the “Email notification” checked.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

Hi @Jules Robichaud-Gagnon, I’ll pass this on to @Shuvy Ankor. He’ll likely only be able to take a look next week

we found the problem. seems like a bug with permit dashboard. To reproduce the problem: 1. On our element we assigned an “Approval Component” and Saved 2. We delete the Approval Component from the Element page 3. We open the Element again and the “approvals” are still there

Thanks for the report - will make sure @Shuvy Ankor and he’s team address this

This problem allowed us to fully test the process in advance to keep the old behaviour. We noticed a problem regarding Element. We were told we could accept the invitation right away in the webhook but it causes a UX problem. The user using Element sees the user as a pending pending unless he refreshes the page. I made a diagram to show the process.

Thanks for the detailed report! I’ll review everything early next week and follow up with you. If you spot any other issues in the meantime, just let us know.

In short. I won’t work on this more until: • new version of the sdk with my PR included is released • element has a fix (if you plan to implement one) For the unexpected approval process when we had none setup: • as a workaround we created a new Element and we deployed it. (we will make sure not to play with approval components with this one). You might have a problem to fix on your side through.

Thank you for your contribution to the Python SDK. I have included it. Thanks for that! (2.8.2)🚀 In addition, we have updated our documentation to clarify how to use it. Our team is working on resolving all the issues here, seeing the recent setbacks we’re zooming out and want to make sure we get this right once and for all. We are postponing any deadlines here until further notice, and we are aiming to have issues here resolved by the of this week, or early next

I was told I might have something to test. What do I have to test?

Hi Jules, @Shuvy Ankor is off for a local holiday he'll be back Thursday. Meanwhile the new Python SDK has been released to the best of my knowledge .

Yeah, the SDK should be ok. But there was other issues. https://permit-io.slack.com/archives/C02RTML2WNN/p1757623471174089?thread_ts=1757431183.137039&cid=C02RTML2WNN

I believe the issue was resolved, but if you want more details or confirmation you'd need to wait for Thursday

Ok, I will wait for the confirmation then. I do not want to test if nothing was fixed. It takes time to be able to test this.

Hi @Jules Robichaud-Gagnon I have several exciting updates to share with you: 1. Released Today: - The fix you requested has been implemented and the contribution you provided was integrated into the previous Python SDK version - Full support for all invite_user functions (list, get, delete) (available from version 2.8.3) 2. Coming This Week: - UI improvements including automatic element refresh after user invitations - Backward compatibility mode with option to hide waiting user lists - Backend performance enhancements for a smoother experience 3. Next Steps: - Auto-deletion of user management component when Access Request component is removed - Node SDK support for all invite user functions Timeline: Everything except the last two items (node sdk+ Auto-delete Access Request ) will be released by mid-next week. --- We’re always looking to improve! Is there any other feature you’d like to see? Your feedback has been invaluable in making our elements better. Thanks for being such an engaged user, and have a wonderful weekend!

@Shuvy Ankor, let me know if what under “Coming This Week” are deployed.

Hi, @Jules Robichaud-Gagnon The automatic refresh feature is now live in production! Please give it a try and let us know what you think. More updates are on the way this week.

only “UI improvements including automatic element refresh after user invitations” or all three? - UI improvements including automatic element refresh after user invitations - Backward compatibility mode with option to hide waiting user lists - Backend performance enhancements for a smoother experience

Everything is now live except for the backward compatibility mode - that should be published tomorrow. It will let you hide the pending users list in your user management element.

is that a permanent feature? because in our use case we would use it

What exactly is the question about?

is it a temporary patch for backward compatiblity to help people for the transition that will be removed eventually?

It will remain, and won't be removed until further notice

Hey @Jules Robichaud-Gagnon, - Backward compatibility mode with option to hide waiting user lists Is now live ln production 🙂

We found 3 problems 1. There is a problem with the toggle in the dashboard, it appears as toggled on even if we toggled it off and saved. (the element will still consider it as toggled off correctly, it only appears wrong in the dashboard). to toggle it on again we need to go back in the dashboard, toggle off, toggle on then save again. (See Screenshot showing a “toggled off” after a save in the dashboard) 2. There is a delay of more than 10 seconds seconds before it updates in Element. With “Pending Users” toggled off, the user will wonder where the invitation went. This is not useable as is. 3. Also with

Pending Users

toggled off, the spot in Element where the “pending users” would appear there is a

0

instead of a blank space (See Screenshot with the pointing arrow). Probably a templating issue.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

no

Hey @Jules Robichaud-Gagnon thanks for the detailed list. I've notified @Alon Boshi and the team of the issues.

Hey @Jules Robichaud-Gagnon, Thanks for flagging this up! We really appreciate any help in improving the system to make it easier for you to use. We'll share a fix for 1 and 3 soon. About 2, I will talk with the team about your concern but for now, the 10-second delay isn’t actually a delay — it’s the expected behavior of the system. Instead of requiring you to refresh the page to see updates, the component automatically refreshes itself every 10 seconds to display the latest changes.