Skip to main content
RapidDev - Software Development Agency
retool-integrationsREST API Resource

How to Integrate Retool with Okta

Connect Retool to Okta using a REST API Resource pointed at https://YOUR_DOMAIN.okta.com/api/v1/. Authenticate with an Okta API token (SSWS token) created in the Okta Admin Console under Security → API → Tokens. Build an enterprise identity admin panel that manages users, groups, and application assignments, and monitors SSO sessions across your organization.

What you'll learn

  • How to create an Okta API token (SSWS token) in the Okta Admin Console
  • How to configure a REST API Resource in Retool for Okta's REST API
  • How to build an Okta user management panel with search, profile editing, group assignment, and suspension controls
  • How to manage Okta groups and application assignments from a Retool admin panel
  • How to query Okta system logs for authentication events and security monitoring
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Intermediate16 min read30 minutesAuthLast updated April 2026RapidDev Engineering Team
TL;DR

Connect Retool to Okta using a REST API Resource pointed at https://YOUR_DOMAIN.okta.com/api/v1/. Authenticate with an Okta API token (SSWS token) created in the Okta Admin Console under Security → API → Tokens. Build an enterprise identity admin panel that manages users, groups, and application assignments, and monitors SSO sessions across your organization.

Quick facts about this guide
FactValue
ToolOkta
CategoryAuth
MethodREST API Resource
DifficultyIntermediate
Time required30 minutes
Last updatedApril 2026

Build an Okta Identity Admin Panel in Retool

Okta is the identity backbone for tens of thousands of enterprises, managing user authentication, application access, and group-based authorization across hundreds of integrated SaaS applications. IT administrators and security teams typically spend significant time in Okta's Admin Console managing user accounts — onboarding new hires, offboarding departed employees, managing group memberships for application access, and reviewing authentication logs for suspicious activity. A Retool panel connected to Okta's Admin API streamlines these workflows, enabling IT staff to perform common identity operations without requiring full Okta Admin Console access.

Okta's API provides complete programmatic control over the identity directory: users can be created, updated, activated, deactivated, and deleted; groups can be created and populated; application assignments can be managed; and the system log provides a comprehensive audit trail of all authentication and authorization events. The Retool integration puts these operations into purpose-built dashboards — an onboarding panel for HR, a user lookup tool for support, and a security log dashboard for the security operations center.

A particularly powerful pattern is building a Retool app that combines Okta data with your HR system or HRIS. When a new employee is added to your HR database, a Retool form or Workflow can automatically create their Okta account, assign them to the appropriate department group (which grants access to department-specific applications), and send them an activation email. When an employee is marked as terminated, the same system can immediately deactivate their Okta account, removing SSO access to all connected applications in one operation — no more manual access revocation across individual apps.

Integration method

REST API Resource

Okta provides a comprehensive REST API (v1) for managing all aspects of enterprise identity: users, groups, applications, policies, and sessions. Retool connects via a REST API Resource using Okta's SSWS (Session Token/API Token) authentication — a static API token created in the Okta Admin Console that is passed as an Authorization header value prefixed with 'SSWS '. The SSWS token inherits the permissions of the admin user who created it, so it should be created by a service account with appropriate read or admin scopes. All requests are proxied server-side by Retool, keeping the SSWS token out of end users' browsers.

Prerequisites

  • An Okta organization (tenant) with Super Administrator or Read-Only Administrator access to create API tokens
  • Your Okta domain (e.g., yourcompany.okta.com or yourcompany.oktapreview.com for preview orgs)
  • An Okta API token created under Security → API → Tokens in the Admin Console
  • A Retool account with permission to create Resources and Configuration Variables
  • Understanding of Okta's permission model: SSWS tokens inherit the role of the creating admin — use a service account with minimum required permissions

Step-by-step guide

1

Create an Okta API token in the Admin Console

Okta's REST API uses SSWS (session) tokens for authentication. Unlike OAuth 2.0 client credentials, SSWS tokens are static tokens tied to the admin account that created them and inherit that account's permissions. To create one, log in to your Okta Admin Console (yourcompany.okta.com/admin/dashboard) with Super Administrator or appropriate admin role. Navigate to Security in the top navigation, then select API from the dropdown. On the API page, click the Tokens tab. Click Create Token. Enter a token name like 'Retool Integration' and click Create Token. Okta displays the token value once — copy it immediately, as it cannot be retrieved again after you close the dialog. This token is an alphanumeric string prefixed with '00' in Okta's format. Store this token in Retool as a Configuration Variable (Settings → Configuration Variables) named OKTA_API_TOKEN marked as a secret. Also store your Okta domain as OKTA_DOMAIN (e.g., yourcompany.okta.com without https://). Best practice: create a dedicated Okta service account (a system admin account that does not belong to a real person) to generate the API token. This prevents the token from being invalidated if the individual admin account is deactivated. Assign the service account the 'Read-Only Administrator' role for read-only dashboards, or 'Organization Administrator' for panels that perform user management operations.

Pro tip: Okta API tokens expire after 30 days of inactivity by default, but remain active as long as they are used at least once every 30 days. Your Retool dashboard queries will keep the token active automatically if the app is used regularly. For dashboards used less frequently, consider setting up a Retool Workflow that pings the Okta API on a weekly schedule specifically to prevent token expiry.

Expected result: An Okta API token has been created, copied, and saved as a secret OKTA_API_TOKEN Configuration Variable in Retool, along with the OKTA_DOMAIN variable.

2

Configure the Okta REST API Resource in Retool

With the SSWS token ready, create the Okta REST API Resource. Navigate to Resources in the left sidebar and click Add Resource. Select REST API. Name the resource 'Okta API'. Set Base URL to https://{{ retoolContext.configVars.OKTA_DOMAIN }}/api/v1 — this constructs the base URL dynamically from the Configuration Variable. Under Authentication, select Header Auth. Add the Authorization header with value SSWS {{ retoolContext.configVars.OKTA_API_TOKEN }} — note the space between 'SSWS' and the token value, and the space between the two parts of the value is required. Unlike Bearer token auth, Okta uses the 'SSWS' prefix in the Authorization header rather than 'Bearer'. Add a second default header Accept: application/json. Click Save and create a test query: GET /users?limit=1 against the Okta API resource. A successful response returns a JSON array with one user object containing profile, credentials, and status fields. If you see 401, verify the Authorization header format is exactly 'SSWS {token}' with no extra characters. If you see 403, the service account creating the token may lack the required Okta admin role.

Pro tip: Okta's API supports rate limiting with specific limits per endpoint. The /users endpoint allows 600 requests per minute, the /system/logs endpoint allows 60 requests per minute, and the /groups endpoint allows 600 requests per minute. Add caching to high-frequency queries (30-60 seconds) to stay well within these limits. The response headers X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset indicate current usage.

Expected result: The Okta API Resource is saved in Retool, and a test GET /users?limit=1 query returns a user object with status 200, confirming the SSWS Authorization header is correctly formatted.

3

Build Okta user management queries

Create the core user management queries. First, 'searchOktaUsers': GET /users. Add URL parameters: q → {{ userSearchInput.value || '' }} (Okta's q parameter searches across firstName, lastName, and email), limit → {{ pagination.pageSize || 25 }}, after → {{ pagination.cursor || '' }} (cursor-based pagination using the 'after' parameter from Link headers). Okta returns user objects with profile (firstName, lastName, email, login, department, title), status (ACTIVE, DEPROVISIONED, SUSPENDED, PASSWORD_EXPIRED, LOCKED_OUT, RECOVERY), and created/lastLogin timestamps. Create a transformer that normalizes this into flat objects for the Table. Create these additional mutation queries: 'deactivateUser' — POST /users/{{ usersTable.selectedRow.id }}/lifecycle/deactivate (suspends Okta access for all connected apps). 'activateUser' — POST /users/{{ usersTable.selectedRow.id }}/lifecycle/activate with query param sendEmail=true. 'unlockUser' — POST /users/{{ usersTable.selectedRow.id }}/lifecycle/unlock. 'resetPassword' — POST /users/{{ usersTable.selectedRow.id }}/lifecycle/reset_password?sendEmail=true. 'expireSessions' — DELETE /users/{{ usersTable.selectedRow.id }}/sessions (terminates all active sessions immediately). Create a 'getUserGroups' query: GET /users/{{ usersTable.selectedRow.id }}/groups to show group memberships for the selected user.

okta_users_transformer.js
1// Transformer: normalize Okta user list for Retool Table
2const users = Array.isArray(data) ? data : [];
3return users.map(user => ({
4 id: user.id,
5 email: user.profile?.email || user.profile?.login || 'N/A',
6 first_name: user.profile?.firstName || '',
7 last_name: user.profile?.lastName || '',
8 display_name: `${user.profile?.firstName || ''} ${user.profile?.lastName || ''}`.trim() || 'Unknown',
9 department: user.profile?.department || '',
10 title: user.profile?.title || '',
11 status: user.status,
12 status_color: {
13 ACTIVE: 'green', SUSPENDED: 'orange', DEPROVISIONED: 'red',
14 LOCKED_OUT: 'red', PASSWORD_EXPIRED: 'yellow', RECOVERY: 'yellow'
15 }[user.status] || 'gray',
16 last_login: user.lastLogin
17 ? new Date(user.lastLogin).toLocaleString()
18 : 'Never',
19 created: new Date(user.created).toLocaleDateString()
20}));

Pro tip: Okta's search uses the 'q' parameter for a simple text search and 'search' for Okta's SCIM filter expressions (e.g., profile.department eq "Engineering" or status eq "ACTIVE" and profile.department eq "Sales"). For complex filtering by department, status, or custom profile attributes, use the 'search' parameter instead of 'q'. The search parameter supports AND/OR operators, equals (eq), not equals (ne), starts with (sw), and comparison operators.

Expected result: User search queries return normalized user objects in the Retool Table, and lifecycle mutation queries (deactivate, activate, unlock, reset password, expire sessions) execute successfully against the selected user.

4

Build the Okta identity admin panel UI

With working queries, build the user management dashboard. Add a Text Input named 'userSearchInput' at the top of the canvas with a Search button that triggers searchOktaUsers. Add a Table component named 'usersTable' bound to {{ searchOktaUsers.data }}. Configure columns: display_name, email, department, title, status (with a colored Tag using the status_color field from the transformer — green for ACTIVE, orange for SUSPENDED, red for DEPROVISIONED or LOCKED_OUT), and last_login. Enable row selection on the table. To the right of the table, add a user detail Container visible only when a row is selected ({{ usersTable.selectedRow !== null }}). Inside the Container, display the selected user's full details using Text components. Add an Action Buttons section with the lifecycle controls — each button has confirmation logic: 'Deactivate Account' (red button, shows Modal: 'This will remove SSO access to all Okta-connected applications for {{ usersTable.selectedRow.display_name }}. Proceed?'), 'Reset Password' (triggers resetPassword query, shows success notification), 'Unlock Account' (visible only when status is LOCKED_OUT), 'Expire Sessions' (logs the user out of all active sessions immediately). Below the user details, add a Groups sub-Table showing the user's current group memberships from getUserGroups, with group name and description. Add a 'Remove from Group' button for each group row that triggers DELETE /groups/{groupId}/users/{userId}.

okta_remove_group_user.json
1// Query config for removing a user from an Okta group
2// DELETE /groups/{groupId}/users/{userId}
3// Path: /groups/{{ usersTable.selectedRow.selectedGroupId }}/users/{{ usersTable.selectedRow.id }}
4// Method: DELETE
5// No body required for DELETE operations
6// On success: trigger getUserGroups to refresh the group membership list

Pro tip: For complex integrations involving Okta SCIM provisioning, automated onboarding/offboarding workflows triggered by HRIS events, group-based access control automation for new application rollouts, and cross-system identity reconciliation, RapidDev's team can help architect and build your Retool enterprise identity management solution.

Expected result: A complete Okta identity admin panel allows IT staff to search users, view status and group memberships, perform lifecycle operations with confirmation modals, and remove users from groups — all without requiring full Okta Admin Console access.

5

Build the Okta System Log security dashboard

Create a security monitoring view using Okta's System Log API (GET /logs). The System Log is the authoritative audit trail for all Okta events — user authentications, admin operations, application access, and policy changes. Create a query 'getSystemLog'. Set Method to GET, Path to /logs. Add URL parameters: filter → {{ logEventFilter.value || 'eventType eq "user.session.start"' }}, limit → {{ logPagination.pageSize || 100 }}, since → {{ new Date(Date.now() - 24*60*60*1000).toISOString() }}, until → {{ new Date().toISOString() }}. The filter parameter uses Okta's SCIM filter syntax. Common event type filters: 'eventType eq "user.authentication.auth_via_IDP"' for SSO logins, 'eventType sw "user.authentication"' for all auth events, 'eventType sw "user.lifecycle"' for user management operations, 'eventType sw "app.oauth2"' for API access events, 'severity eq "WARN" or severity eq "ERROR"' for security alerts. Create a transformer that normalizes log entries: extract eventType, displayMessage, severity (INFO/WARN/ERROR), actor (the user who performed the action), target (the affected resource), client IP, and timestamp. Display in a Table with severity color coding (ERROR = red, WARN = orange, INFO = gray). Add a Bar Chart above the table showing event count by hour for the selected time range, using a GROUP BY hour transformation over the log data. Add a Select component for event type filter with pre-set options for common security event types.

okta_system_log_transformer.js
1// Transformer: normalize Okta System Log entries
2const events = Array.isArray(data) ? data : [];
3return events.map(event => ({
4 timestamp: new Date(event.published).toLocaleString(),
5 event_type: event.eventType,
6 display_message: event.displayMessage,
7 severity: event.severity,
8 actor_name: event.actor?.displayName || event.actor?.alternateId || 'System',
9 actor_type: event.actor?.type || '',
10 target: event.target?.[0]?.displayName || event.target?.[0]?.alternateId || '',
11 client_ip: event.client?.ipAddress || 'N/A',
12 geo_location: event.client?.geographicalContext
13 ? `${event.client.geographicalContext.city}, ${event.client.geographicalContext.country}`
14 : 'Unknown',
15 outcome: event.outcome?.result || '',
16 reason: event.outcome?.reason || ''
17}));

Pro tip: Okta's System Log is rate-limited to 60 requests per minute. For security dashboards that update frequently, enable query caching with a 60-second TTL to avoid hitting this limit during active monitoring sessions. The System Log retains events for 90 days on most Okta plans — for compliance requirements needing longer retention, set up a Retool Workflow that exports System Log events daily to your data warehouse or SIEM.

Expected result: The security monitoring tab displays Okta System Log events with severity color coding, a time-series chart of event volume, and filters for event type — enabling security analysts to detect suspicious authentication patterns and review admin operations.

Common use cases

Build an IT user management and offboarding panel

Create a Retool IT operations panel that allows helpdesk staff to search for Okta users by name or email, view their profile, group memberships, and active application assignments. Include one-click actions to deactivate an account (suspends SSO access to all connected apps), reset password via email, expire active sessions, and reassign MFA factors. The panel replaces the need for helpdesk staff to have full Okta Admin Console access.

Retool Prompt

Build a Retool Okta IT management panel. A search bar finds users by email or name. On selection, show the user's profile, status, group memberships, and assigned applications in collapsible sections. Include action buttons: Deactivate Account, Reset Password, Expire Sessions, and Unlock Account. Each button shows a confirmation modal before executing.

Copy this prompt to try it in Retool

Build a group membership and application access manager

Create a Retool access management panel for IT administrators to manage Okta group memberships and application assignments. View all groups with member counts, click a group to see its members and assigned applications, add or remove users from groups in bulk, and create new groups for department or project access. This panel supports the access management lifecycle without requiring users to navigate Okta's multi-screen group management interface.

Retool Prompt

Build a Retool Okta group manager. A Table lists all Okta groups with name, description, and member count. Selecting a group shows two sub-Tables: group members (with remove buttons) and assigned applications. Add an 'Add User to Group' button that opens a user search modal. Include a 'Create Group' form with name and description fields.

Copy this prompt to try it in Retool

Build a security log and authentication monitoring dashboard

Create a security operations Retool dashboard that queries Okta's System Log for authentication events — failed logins, MFA challenges, suspicious IP activity, and admin operations. Filter events by type, user, time range, and IP address. Show a Chart of authentication failures over time to identify brute force patterns, and a Table of recent admin operations for compliance auditing.

Retool Prompt

Build a Retool Okta security dashboard. Query the Okta System Log API for the last 24 hours. Show a Line Chart of total events, failed logins, and MFA failures over time. A Table below shows filterable events with: timestamp, event type, user, IP, outcome, and severity. Add filters for event type and date range. Highlight failed login events in red.

Copy this prompt to try it in Retool

Troubleshooting

401 Unauthorized on all Okta API calls — 'Invalid token provided'

Cause: The SSWS token is either expired, has been revoked in the Okta Admin Console, or the Authorization header is formatted incorrectly. Okta SSWS tokens expire after 30 days of inactivity and can also be manually revoked.

Solution: Log in to your Okta Admin Console, navigate to Security → API → Tokens, and check whether the token is listed as active. If expired or revoked, create a new token and update the OKTA_API_TOKEN Configuration Variable in Retool. Verify the header format in the Retool Resource is exactly: key=Authorization, value=SSWS {token_value} — the space after 'SSWS' is required and the prefix must be uppercase 'SSWS', not 'Bearer' or 'Token'.

Okta API returns 403 Forbidden — 'You do not have permission to access the feature you are requesting'

Cause: The Okta service account that created the API token does not have the required admin role for the operation being attempted. Read operations require at minimum 'Read-Only Administrator', while write operations (lifecycle changes, group management) require 'Organization Administrator' or 'Group Administrator' roles.

Solution: In the Okta Admin Console, go to Security → Administrators and find the service account used to create the API token. Review its assigned admin role and add the appropriate elevated role. After updating the role, generate a new API token from the service account — existing tokens do not automatically inherit new permissions. Update the OKTA_API_TOKEN Configuration Variable with the new token.

User lifecycle mutation queries (deactivate, activate) return 404 Not Found

Cause: The user ID passed in the query path (usersTable.selectedRow.id) is incorrect, null, or using the user's login/email instead of Okta's internal user ID (a 20-character alphanumeric string starting with '00u').

Solution: Verify the transformer maps the user's id field correctly — in the Okta API response, the user ID is at the top level of the user object (user.id), not inside user.profile. Log {{ usersTable.selectedRow.id }} in a temporary Text component to confirm the correct Okta user ID format (e.g., 00u1a2b3c4d5e6f7g8). Ensure the query path uses /users/{{ usersTable.selectedRow.id }}/lifecycle/deactivate exactly, with no extra characters.

System Log query returns empty results despite events existing in the Okta Admin Console

Cause: The 'since' or 'until' timestamp format is incorrect (Okta requires RFC 3339 / ISO 8601 format), or the 'filter' parameter syntax is malformed, causing the API to return an empty result set rather than an error.

Solution: Verify timestamp format: Okta requires ISO 8601 format with timezone offset, e.g., '2024-01-15T00:00:00.000Z'. The JavaScript new Date().toISOString() method generates the correct format. Test without the filter parameter first to confirm the time range returns results. Then add the filter incrementally — if the filter causes empty results, check for syntax errors in the SCIM expression (strings must be quoted with double quotes within the filter value).

typescript
1// Correct Okta System Log filter format
2// Filter for failed authentication events
3'eventType eq "user.authentication.auth_via_form_factor" and outcome.result eq "FAILURE"'
4
5// Filter for admin operations in last 24 hours:
6// since parameter: new Date(Date.now() - 24*60*60*1000).toISOString()

Best practices

  • Create a dedicated Okta service account (not tied to an individual employee's identity) for the API token — this prevents the Retool integration from breaking when team members leave or change roles, and allows you to assign minimum-privilege admin roles
  • Use 'Read-Only Administrator' role for monitoring and lookup dashboards, and 'Organization Administrator' only for panels that perform lifecycle operations — applying principle of least privilege to the service account reduces risk if the SSWS token is compromised
  • Store the SSWS token in a Retool Configuration Variable marked as a secret and set up a quarterly token rotation reminder — Okta tokens expire after 30 days of inactivity, and a fresh token rotation policy limits exposure from a potentially compromised token
  • Add confirmation modals to all lifecycle operations (deactivate, suspend, delete) with the affected user's name and email clearly displayed — Okta operations take immediate effect on all connected SSO applications and cannot be undone without another API call
  • Use Okta's 'search' parameter with SCIM filters for advanced user queries rather than fetching all users and filtering client-side — Okta directories can contain tens of thousands of users, and server-side filtering is dramatically faster
  • Cache the groups list query (60 seconds TTL) since Okta groups change infrequently — this improves dashboard load time for the group management panel without significantly impacting data freshness
  • Log all user management operations performed through the Retool panel in a local audit table (INSERT with: action, affected_user_email, performed_by, timestamp) as a supplementary audit trail — Okta's System Log is the authoritative source, but a local log gives IT managers a quick dashboard-level view of recent operations

Alternatives

Frequently asked questions

Does Retool have a native Okta connector?

No, Retool does not have a native Okta connector. You connect via a REST API Resource using Okta's Admin API with SSWS (session/API token) Bearer-style authentication. Despite the manual setup, this approach gives full access to Okta's complete API — users, groups, applications, policies, and system logs — enabling comprehensive identity management panels.

What is an Okta SSWS token and how is it different from OAuth 2.0?

An Okta SSWS (Session Token) is a static API token created in the Okta Admin Console that persists until manually revoked or expired from 30 days of inactivity. Unlike OAuth 2.0, there is no token refresh flow — the SSWS token is long-lived by design for server-side API integrations. It inherits the permissions of the admin account that created it and is passed in the Authorization header as 'SSWS {token}'. Okta also supports OAuth 2.0 for service-to-service (client credentials) API access as an alternative, which is recommended for higher-security environments.

Can I provision new Okta users from Retool?

Yes. Use a POST request to /api/v1/users with the user's profile information (firstName, lastName, email, login) and desired initial password or activation method in the request body. Set the activate query parameter to true to immediately activate the account or false to create it in a STAGED state. After creation, assign the user to appropriate groups using POST /api/v1/groups/{groupId}/users/{userId} to grant application access based on group-based assignments.

How do I immediately revoke all Okta access for a terminated employee?

A complete offboarding requires two sequential Okta API calls: first, DELETE /api/v1/users/{userId}/sessions to terminate all active browser sessions (instant effect across all SSO apps), then POST /api/v1/users/{userId}/lifecycle/deactivate to set the account status to DEPROVISIONED, which prevents future logins. The deactivation is immediate and affects all Okta-integrated applications simultaneously — no need to manually revoke access in each individual app that uses Okta SSO.

Can I view which applications a specific user has access to through Okta?

Yes. Use the endpoint GET /api/v1/apps?filter=user.id eq "{userId}" to list all Okta applications assigned to a specific user. Each application object includes appId, label (display name), status, and signOnMode. Alternatively, GET /api/v1/users/{userId}/appLinks returns the app links assigned to the user with their direct SSO URLs — useful for building a 'My Apps' style view in a Retool panel.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Integrations are where projects stall

We wire Retool integrations like this one every week — auth, webhooks, edge cases included. Fixed-price builds from $13K, delivered in 6–10 weeks.

Talk to an integration engineer

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.