Skip to main content
Use the @bijectionhq/connectors/workos-enterprise entrypoint to declare WorkOS enterprise health resources.

​
Availability

This page describes the pinned source package. Published availability is unestablished for this artifact. Source build and package availability.

​
Resources and modes

Declare a resource in application code, then bind deployment-specific settings and credentials. See typed resources, connections and source inspection.

​
Reviewed connection, directory and certificate health

​
observations: Current provider observations

The following example matches configuration standard.

​
Configuration: standard

Case: workos-enterprise/health/observations/standard. Connection and resource configuration are declared by this exact case. Credential kind: workos. Keep credential material in the private credential inventory. Inspect the complete configuration contract below for settings and conditional requirements.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Verification scope Each evidence category has independent scope. A matching recorded pass applies only to its exact artifacts and configuration. Installed connections report their own identity, authority and current status.

​
Provider guidance

Bind the resulting source through the normal native connection owner to https://api.workos.com and a workos credential. The reviewed organization and connection IDs are fixed in code. Directory selection is optional and exact. Read the source row under the same organization authorization as its setup. Native acquisition reads the organization, selected connection, selected directory, and the connection’s IdP signing certificate list. Certificate material is discarded; only IDs and validity dates are published. The certificate API is feature flagged: 403/404 is unavailable evidence, never an empty certificate list. Active connection state proves neither an SSO ceremony nor enforcement of SSO for all sign-ins. The API does not expose an enforcement fact here, so ssoEnforced stays null. Use defineWorkosEnterpriseHealth with a fixed internal query of this source row, its record evidence and source inspection subject. The factory produces separate connection and certificate proofs. It never substitutes acquisition completion time for native observation time, never treats directory active/linked as complete membership coverage, and never claims a consumed event cursor was applied. Use the original directory source’s evidence for the separate directory proof. Ordered WorkOS events trigger refreshes; periodic reads bound missed notifications. Refresh/reconnect/rebaseline go through the existing source and connection controls. Only successful native rereads establish new readiness evidence. Unknown states and expired record observations fail closed. No provider action is repeated by a proof. References: connections, certificates, directories.

​
Install readiness proofs

Add an enterpriseProviderHealth resource parented by organization with read permission, and grant its readers explicitly in the application’s roles. Keep provider observations source-owned:
The diagnostic table permits stale reads so status can explain them. The proof owner independently requires current native record evidence. Bind the scoped resource with the normal deployment bind(resources.workos.health, {setup:{}, credential:workosEnterprise.credential('WORKOS'),scope:{organizationId}}). Install the concrete source reader. Its configuration query returns {configuration:{issuer,clientId,providerOrganization},selection:{connection,directory}} from the local organization’s reviewed settings. Share the reviewed selection with workos.ts; callers never submit it. Reads retain the source table’s ordinary authorization and the fixed owner index.
The reader strips local metadata and obtains evidence from ctx.sources.evidence({sourceId:row._sourceId},{record:row._id}). An absent row returns unavailable input. A different owner or missing native source provenance refuses. It creates an inspection subject under the same fixed read owner. Custom fixed readers can supply additional directory evidence under workosEnterpriseHealthObservation; no public endpoint accepts acquired facts.
Register the factory’s inspectionOwner in the application’s existing inspection owners to resolve its source references. Add workosConnection:internal.workosHealth.connectionProof and, for a SAML configuration requiring certificate readiness, workosCertificate:internal.workosHealth.certificateProof to the existing defineEnterpriseSetup({proofs:...}). The enterprise starter doctor reports these named installed proofs and their actual outcomes. Keep the native SSO canary: connection and certificate proofs establish different facts. The optional directoryEvidence input names its exact reviewed directory, inspection source, and the original membership source’s native evidence. directoryProof needs complete population coverage, freshness, a provider checkpoint and an applied publication ID independently. The health row cannot supply these. WorkOS live paginated directory observations currently offer positive records without snapshot coverage; they cannot pass a complete population proof. Use per-record freshness for authorization and keep full coverage unavailable until the source actually proves it. policyProof remains unavailable: these read APIs supply no authoritative all-methods SSO enforcement fact. Install a separate fixed policy owner if the provider makes that evidence available. Do not activate a policy-dependent setup by inferring enforcement from a successful SSO login.

​
Provider references

Provider references and prerequisites are maintained in the connector guidance above. No separate provider-documentation review date is recorded.

​
Source and evidence

Canonical connector source, native analysis and check receipts. Connector artifact: 455b2e3ba5a436b66a8f4c3fb2b05a442c4711673952d2f858e9da4ebdc097d6. The resource declaration examples above are compiled and compared with exact catalog declarations. Recorded checks apply only to their source, declaration and runtime identities. Configure a connection and inspect its status to establish deployment-specific readiness.