WorkOS Connector

Illustration · sample data

Sync example

Review one record

Source

WorkOS

Connector status: In progress

→

Destination

Your other tool

Connector status: Custom tool

Field mapping

Source field	Destination field	Sample value
record.id	source_id	record_1042
record.updated_at	updated_at	2026-10-18T08:00:00Z
record.value	value	sample_value

1. Draft
2. Review one record
3. Approve this version

Statuses describe individual connectors; they do not guarantee this sync is ready. Illustrative fields. Review the actual schema and permissions before a sync runs.

Implementation Overview

Property	Value
Integration surface	OpenAPI
Status	In progress
Category	Identity & SSO
Setup complexity	medium
Vendor documentation	workos.com/docs/reference
Allowed host	Not recorded
Base URL	Not recorded
OpenAPI schema	github.com/workos/openapi-spec/blob/main/spec/open-api-spec.yaml
MCP server	Not recorded
Last researched	2026-10-30

Official OpenAPI 3.1.1 document (MIT); eight operations vendored. Bearer API key (sk_test_ for staging, sk_live_ for production; the body is the base64 of key_…). Lists page by after in creation order; no updated-since filter, so deltas read the Events API (90 days kept, 30 days a request). AuthKit is free up to 1 million monthly active users, with a staging environment.

Authentication

• Use github.com/workos/openapi-spec/blob/main/spec/open-api-spec.yaml to generate or validate typed API clients and request models.

• Keep workos.com/docs/reference linked from the connector runbook so operators can confirm vendor behavior during incidents.

• Store credentials per Tajo workspace and keep tenant-specific secrets out of connector configuration files.

• Add a credential smoke test that verifies read access to a harmless resource before running backfills or enabling webhooks.

Data To Sync

Start with these inferred data domains, then confirm exact vendor resources and permissions from the source documentation:

• Contact and identity records

The connector should make source records idempotent by keeping a stable key such as a vendor object ID, email address, event ID, ticket ID, order ID, or campaign ID. If the vendor only exposes list APIs, Tajo should store the cursor strategy and replay policy explicitly.

Sync Shape

Resource	Direction	Conflict handling
users	bidirectional	source_wins, loop guard none
user_changes	inbound	n/a
organizations	inbound	n/a
organization_changes	inbound	n/a
organization_memberships	inbound	n/a
membership_changes	inbound	n/a
directories	inbound	n/a
directory_users	inbound	n/a
directory_user_changes	inbound	n/a
directory_groups	inbound	n/a

WorkOS is the record of its users; the one write back (update_user) sets names and metadata keys the buyer names, which no read here turns into a write again.

Mapping To Tajo/Brevo

users → Brevo contact

Requires: custom attribute creation.

Source field	Brevo destination	Via	Note
tajo_email_marketing_consent	filter	—	the canonical consent pair: consent is always false (WorkOS records no marketing consent), so no user passes on WorkOS’s record alone

Read for context and not projected: user_changes, organizations, organization_changes, organization_memberships, membership_changes, directories, directory_users, directory_user_changes, directory_groups.

The conventions that apply to every connector — stable external IDs, normalization, backfill and sync strategy, error handling, and the builder checklist — are documented once under “Applies to every connector” on the connector catalog.

Sources

• Vendor documentation
• OpenAPI or schema source
• github.com/workos/openapi-spec
• workos.com/docs/events/data-syncing/events-api
• workos.com/docs/reference/rate-limits
• workos.com/pricing