Clerk Connector
Connector status: In progress Being built. Not verified yet.
Illustration · sample data
Sync example
Source
Clerk
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 |
- Draft
- Review one record
- 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.
Connector implementation
Build the Clerk integration
Authentication and user management for web and mobile apps, with organizations for B2B
Implementation Overview
Implement a Clerk connector that authenticates to the vendor surface, normalizes source records in Tajo, and activates eligible data in Brevo.
Treat this as an implementation guide. Build and validate the auth, mapping, sync, and operations paths before production use.
github.com/clerk/openapi-specs/blob/main/bapi/2026-08-20.yml
| Property | Value |
|---|---|
| Integration surface | OpenAPI |
| Status | In progress |
| Category | Identity & SSO |
| Setup complexity | medium |
| Vendor documentation | clerk.com/docs/reference/backend-api |
| Allowed host | Not recorded |
| Base URL | Not recorded |
| OpenAPI schema | github.com/clerk/openapi-specs/blob/main/bapi/2026-08-20.yml |
| MCP server | Not recorded |
| Last researched | 2026-10-30 |
Official Backend API OpenAPI 3.0.3 document, versioned by date (2026-08-20 used, pinned with the Clerk-API-Version header); four operations vendored. Bearer Secret Key (sk_test_ for development instances, sk_live_ for production). Users page by starting_after; no updated-since filter, so deltas are on created_at and last_sign_in_at. The free Hobby plan includes development instances.
Authentication
-
Use github.com/clerk/openapi-specs/blob/main/bapi/2026-08-20.yml to generate or validate typed API clients and request models.
-
Keep clerk.com/docs/reference/backend-api 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_signups | inbound | n/a |
user_sign_ins | inbound | n/a |
organizations | inbound | n/a |
organization_memberships | inbound | n/a |
Clerk is the record of its users; the one write back (update_user_public_metadata) merges keys the buyer names into public metadata, 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 (Clerk records no marketing consent), so no user passes on Clerk’s record alone |
Read for context and not projected: user_signups, user_sign_ins, organizations, organization_memberships.
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.