Time Doctor

Before writing a single workflow in Bubble, you need two things from Time Doctor: OAuth credentials and your company ID. The company ID is visible immediately — log in at https://2.timedoctor.com and look at the URL after the domain. The number that appears (e.g., https://2.timedoctor.com/123456/dashboard) is your company ID. Copy it somewhere safe. For OAuth credentials, Time Doctor does not offer self-service API key generation in the standard account dashboard. You need to either submit a request through the Time Doctor integrations portal or contact their support team explaining that you are building a custom integration. This process can take several business days — start this step well before your build deadline. When Time Doctor confirms your OAuth application, you will receive a Client ID (a public identifier) and a Client Secret (treat this like a password — never share it or put it in client-side code). Keep both values in a secure place; you will enter them into Bubble as App Constants in the next step. Verify that your Time Doctor account is on v2 — the v2 dashboard URL is 2.timedoctor.com. The older v1.1 interface is at timedoctor.com with a different URL structure. If you see a different domain pattern, contact Time Doctor support to confirm which API version your account uses, because v1.1 and v2 have entirely separate auth systems and mixing credentials between them produces 401 errors with no version-mismatch explanation.

In Bubble, sensitive values like OAuth secrets should be stored as App Constants rather than hardcoded into workflow expressions. App Constants let you reference a value by name across all workflows without exposing the literal string in the visual editor. To add App Constants, click the Settings icon in the left sidebar, then go to the App data tab. Scroll down to find the App Constants section and click 'Add a constant'. Create three constants: 1. Name: TD_CLIENT_ID — Value: paste your Time Doctor Client ID — leave Private unchecked (Client IDs are not secret) 2. Name: TD_CLIENT_SECRET — Value: paste your Client Secret — tick the Private checkbox (this hides the value in the editor and excludes it from client-side exposure) 3. Name: TD_COMPANY_ID — Value: paste your numeric company ID — leave Private unchecked The Private checkbox on TD_CLIENT_SECRET is important: it prevents the value from appearing in Bubble's debugger output and ensures it is only accessible in server-side contexts (Backend Workflows and API Connector calls with Private headers). Never paste the client secret directly into a text expression visible in the workflow editor — use the App Constant reference instead. Once all three constants are saved, click back to the main editor. In the next step you will build the Backend Workflow that uses these constants to mint an OAuth token.

Backend Workflows in Bubble run entirely on Bubble's servers and can safely hold Private App Constants. You will build a workflow that (a) POSTs to Time Doctor's token endpoint to get a fresh access token, (b) stores the token and its expiry time in a Bubble Data Type, and (c) can be called from any other workflow that needs a valid token. First, create a Data Type to cache the token. Go to the Data tab → Data types → Add a type → name it 'TD_TokenCache'. Add these fields: access_token (text), expires_at (date). You will use a single record in this type as a rolling cache. Next, go to Backend Workflows (Settings → API → check 'This app exposes a Workflow API', then click 'Backend workflows' in the left sidebar). Create a new API Workflow named 'refresh_td_token'. Inside this workflow, add an 'API Connector call' action and configure it to POST to the Time Doctor token endpoint. Since you are inside a Backend Workflow, you can reference the Private App Constant safely. In the API Connector, create a new API group named 'Time Doctor OAuth'. Add one call named 'Get Token' with the following configuration: - Method: POST - URL: https://api2.timedoctor.com/oauth/v2/token - Body type: Form data (application/x-www-form-urlencoded) - Body parameters: - grant_type = client_credentials - client_id = [App Constant TD_CLIENT_ID] - client_secret = [App Constant TD_CLIENT_SECRET] — mark this parameter Private Initialize this call by clicking 'Initialize call' — Bubble needs a real successful response to detect the response fields. Use your actual credentials; you should see access_token appear in the detected fields. Back in the Backend Workflow, after the token call, add a 'Make changes to a Thing' step: find or create the TD_TokenCache record, set access_token = result of Get Token's access_token, and set expires_at = Current date/time + (the token TTL in seconds — check the expires_in field from the response, typically 3600 seconds = 1 hour). This cached record is what all other workflows will read before making a Time Doctor API call. Before calling any Time Doctor endpoint, add a condition check at the start of every downstream workflow: if TD_TokenCache's expires_at is in the past (or the record does not exist), trigger 'refresh_td_token' first; otherwise use the cached access_token directly. This avoids unnecessary token-mint round-trips on every page load.

1{
2  "method": "POST",
3  "url": "https://api2.timedoctor.com/oauth/v2/token",
4  "headers": {
5    "Content-Type": "application/x-www-form-urlencoded"
6  },
7  "body": {
8    "grant_type": "client_credentials",
9    "client_id": "<App Constant TD_CLIENT_ID>",
10    "client_secret": "<App Constant TD_CLIENT_SECRET — Private>"
11  },
12  "expected_response": {
13    "access_token": "eyJhbGciOi...",
14    "token_type": "Bearer",
15    "expires_in": 3600
16  }
17}

With the token-exchange workflow in place, you can now build the actual data calls. In the API Connector (Plugins tab → API Connector → add calls to your 'Time Doctor OAuth' group or create a new group named 'Time Doctor Data'), configure the following two calls: **Call 1: Get Worklogs** - Name: Get Worklogs - Method: GET - URL: https://api2.timedoctor.com/api/1.0/[App Constant TD_COMPANY_ID]/worklogs - Headers: Authorization = Bearer [value from TD_TokenCache's access_token] — mark Private - Query parameters: - start_date = <dynamic> (format: YYYY-MM-DD) - end_date = <dynamic> - user_id = <dynamic> (optional; omit to get all users) - Use as: Data - Initialize: Click 'Initialize call' with a real date range that has tracked hours — use today's date minus 7 days as start_date. Bubble will detect the response fields including user_id, task_id, project_id, and worklog values. **Call 2: Get Team Members** - Name: Get Users - Method: GET - URL: https://api2.timedoctor.com/api/1.0/[App Constant TD_COMPANY_ID]/users - Headers: Authorization = Bearer [same cached token] — mark Private - Use as: Data - Initialize: Click 'Initialize call'; Bubble will detect id, name, email, and role fields. For both calls, the Authorization header value must be constructed dynamically as 'Bearer ' + TD_TokenCache's access_token. In Bubble's API Connector, use the dynamic value picker to concatenate the prefix with the cached token value. Mark the Authorization header Private on both calls. After initializing both calls, create a 'TD_Worklog' Data Type with fields matching the detected worklog response fields (user_id as text, project_id as text, task_id as text, hours as number, date as date). This Data Type lets you optionally persist worklogs locally for faster repeated loads rather than fetching from Time Doctor on every page visit.

1{
2  "Get_Worklogs": {
3    "method": "GET",
4    "url": "https://api2.timedoctor.com/api/1.0/{companyId}/worklogs",
5    "headers": {
6      "Authorization": "Bearer <cached access_token — Private>"
7    },
8    "query_params": {
9      "start_date": "<dynamic YYYY-MM-DD>",
10      "end_date": "<dynamic YYYY-MM-DD>",
11      "user_id": "<dynamic — optional>"
12    }
13  },
14  "Get_Users": {
15    "method": "GET",
16    "url": "https://api2.timedoctor.com/api/1.0/{companyId}/users",
17    "headers": {
18      "Authorization": "Bearer <cached access_token — Private>"
19    }
20  }
21}

Now build the actual productivity dashboard that team members and managers will use. Create a new Bubble page named 'productivity-dashboard'. The page needs three UI components: a date range picker, a user filter dropdown, and a Repeating Group for worklog results. Date range: Add two Date/Time Picker elements — one for 'Start Date' and one for 'End Date'. Connect them to two Custom States on the page (type: date) named 'filter_start' and 'filter_end'. Set default values to 7 days ago and today respectively. User filter: Add a Dropdown element. Set its Choices source to 'Get Users' API Connector call. Set the option label to the 'name' field and the value to the 'id' field. Add a 'All Users' placeholder option. Connect the selected value to a Custom State named 'filter_user_id'. Worklog Repeating Group: Add a Repeating Group with Type of Content = 'Get Worklogs result'. In the Data source field, select 'Get Worklogs' from the API Connector. Pass the dynamic parameters: - start_date = Custom State filter_start (formatted as YYYY-MM-DD) - end_date = Custom State filter_end (formatted as YYYY-MM-DD) - user_id = Custom State filter_user_id (leave blank if the 'All Users' option is selected) Inside each Repeating Group cell, add text elements displaying: current cell's user_id (or look up the name from the Get Users call), project_id, task name, date, and hours. For a visual summary, add a Text element that calculates total hours by doing a search across all visible cells — use a 'Calculate formula' expression summing the hours field. Token validity check: Add a 'Page is loaded' workflow. The first action checks if TD_TokenCache's expires_at is less than Current date/time (or if no record exists). If true, run the 'refresh_td_token' Backend Workflow as a schedule (immediate), then set a wait for the token to be ready before the Repeating Group loads. This ensures the dashboard always opens with a valid token. RapidDev's team has built hundreds of Bubble apps with integrations like this, including multi-user productivity dashboards that combine Time Doctor data with Bubble's native database for deeper reporting — get a free scoping call at rapidevelopers.com/contact.

Before considering the integration production-ready, run a full end-to-end test in Bubble's debugger to catch any silent failures. Open the Bubble debugger (Preview the app → click 'Debug mode' in the top bar). Navigate to the productivity dashboard page. Watch the Step-by-step panel as the 'Page is loaded' workflow runs: 1. Confirm the token validity check evaluates correctly — if TD_TokenCache is empty, the refresh_td_token Backend Workflow should trigger and complete before data loads. 2. Watch the Get Worklogs API Connector call fire. Check the returned data: does it contain the expected fields? Are the user_id, project_id, and hours values populated? 3. If the call returns an empty response, check your date range — use a range that covers days with real tracked hours (not weekends or days before Time Doctor was set up). 4. Test the user filter: select a specific team member from the dropdown and confirm only that user's worklogs appear. 5. Check the Logs tab (Settings → Logs → Workflow logs) to see the API calls that fired, their WU cost, and any error responses. Time Doctor API calls that return 401 after setup typically mean the cached token has expired or was stored incorrectly. For rate limiting: Time Doctor does not publish a specific rate limit. Avoid triggering the Get Worklogs call on every keystroke in the date pickers — use a 'Search' button to trigger the Repeating Group refresh instead of live-updating on date-picker change, to minimize unnecessary API calls and WU consumption. Once the test is clean in debugger mode, deploy the app (Deploy → Live) and verify the dashboard works in the live environment. Backend Workflows behave identically in test and live, but always confirm with a real deployment before sharing with the team.