Hi everyone,
I’m trying to integrate the Nylas Scheduler Editor using the code snippet provided in their documentation. I copied the code as it is and just updated the client ID with mine. The Google authentication flow works fine – I see the Auth Provider options, and after successful authentication, it doesn’t show any error.
However, the Scheduler Editor UI doesn’t appear after authentication completes.
Here is what I did:
Used the exact demo code from the Nylas docs.
Updated client ID and redirect URL to mine.
Added the redirect/callback URL in my Nylas dashboard as well.
Authentication flow completes successfully, but the editor is not displayed.
Is there something else I need to configure after authentication to render the Scheduler Editor? Any additional redirect URLs, environment variables, or backend setup needed?
Any guidance would be appreciated.
Thanks in advance!
I’ve used that code
Nylas Scheduler Editor Component
body {
font-family: "Inter", sans-serif;
}
I am integrating it with Bubble so any help would be appreciated.
After a successful authentication flow using the Scheduler Editor Component, you should not need additional backend setup, environment variables, or redirect URLs beyond what you described for basic usage. The main requirements are:
Correctly setting the clientId and redirectUri in your nylasSessionsConfig object.
Ensuring the redirectUri matches what is registered in your Nylas Dashboard.
Including the Scheduler Editor web component and calling defineCustomElement().
Here’s the essential HTML/JS code from the docs for reference:
The Scheduler Editor UI should appear after authentication if the component is mounted and configured as above.
Make sure the <nylas-scheduler-editor /> tag is present in the DOM at the time of mounting and after authentication completes.
The authentication redirect should route the user back to the page where the Scheduler Editor is mounted (the URL must match the redirectUri).
If you are using a frontend framework (like Bubble) that dynamically mounts/unmounts elements, ensure the custom element is not being removed from the DOM after the OAuth redirect.
No additional environment variables or backend setup is required for the basic use case described in the docs.If you are integrating with Bubble, you must ensure:
The authentication redirect returns the user to a page where <nylas-scheduler-editor /> is present and defineCustomElement() is called again if needed.
Bubble’s page routing and SPA logic do not interfere with the mounting and lifecycle of custom elements.
If the above steps are followed and the UI still does not render, consider checking browser console logs for errors, as there may be issues related to how Bubble handles custom elements or JavaScript modules.
Hi Sam, thank you for getting back to me. I’m running into a couple of issues during the integration of the Scheduler Editor component into my Bubble app. First, while I do receive the authorization code in the redirect URL and the client ID and redirect URI are correctly set up, the code does not seem to be exchanging for an access token. The logs show a 400 (Bad Request) response from the token endpoint, which makes me wonder if Bubble is affecting the redirect or the way parameters are passed. Second, after the redirect and rendering of the Scheduler Editor, I encounter CORS-related errors when the component tries to fetch calendars. The browser blocks the request with a “No ‘Access-Control-Allow-Origin’” error, followed by a 401 Unauthorized, which suggests either the token isn’t available due to the failed exchange or the calendar endpoint isn’t accessible from the frontend. From what I understand, the Scheduler Editor is supposed to handle the OAuth flow on its own, but it seems fetching calendars may require a backend proxy to avoid CORS restrictions. Since Bubble is frontend-heavy, would you recommend offloading the token exchange and calendar fetching to server-side actions? Or is there a way to ensure the Scheduler Editor can handle everything internally? Let me know what the best approach would be — happy to share more logs or context if needed. Best regards, Aliza