WorkOS Free Credits: $1,000 in credits

Deal Highlights

Every B2B SaaS company hits the same wall. A large customer loves the product, the deal is nearly closed, and then their security team sends a questionnaire requiring SAML single sign-on, directory sync, and audit logs. None of that exists in your product, and building it properly is weeks of specialized work against protocols that are older and stranger than anything else in your stack. WorkOS exists to make that a configuration task instead of a quarter of engineering.

WorkOS provides the enterprise features that unlock enterprise deals, delivered as clean APIs so you add them to authentication you already have rather than rebuilding your login system.

What Is WorkOS?

WorkOS is a platform of enterprise-readiness APIs for B2B SaaS. Its original and still central product is single sign-on: a single integration that connects your app to the many identity providers enterprises use, Okta, Microsoft Entra, Google Workspace, OneLogin, and the long tail of SAML providers, without you implementing each one.

Around SSO it has expanded into the rest of the enterprise checklist. Directory Sync (SCIM) automatically provisions and deprovisions users when a customer adds or removes an employee. Audit Logs produce the tamper-evident activity records security teams require. AuthKit provides full user management and authentication for teams that want it. There are also newer additions for fine-grained authorization, admin self-service, and integrations.

The strategic point is narrow and important: WorkOS is not trying to be your entire auth system. It is the layer that makes your existing product sellable to enterprises, which is a specific and valuable job.

What's Included in This Deal

• $1,000 in credits applied against WorkOS usage
• Single Sign-On across SAML and OIDC identity providers
• Directory Sync (SCIM) for automated user provisioning
• AuthKit for user management and authentication
• Admin Portal, a hosted page where customer IT admins self-configure their identity provider
• API and SDK access across the platform

Against WorkOS's per-connection pricing, $1,000 covers your first several enterprise connections, which is precisely the window where the revenue from those deals has not yet arrived but the feature is blocking them.

WorkOS Pricing: The Per-Connection Model

WorkOS prices differently from most auth tools, and understanding the model is essential because it changes which vendor is cheapest for you.

Most authentication platforms charge per monthly active user. WorkOS charges per connection, where a connection is one enterprise customer's link to their identity provider, regardless of how many employees sit behind it.

The per-connection ladder matters. SSO starts near $125 per connection and steps down as you add more, reaching much lower per-connection rates at scale, with volume discounts applied automatically rather than through a sales call up to a high threshold.

Two facts change the arithmetic. First, a customer needing both SSO and SCIM is billed for both, so an entry-level connection requiring provisioning as well as login costs roughly double the headline SSO figure. Second, the model is blind to seat count: a connection for a ten-person customer and a connection for a ten-thousand-person customer cost the same. That is the whole reason to prefer per-connection pricing, because enterprise customers are exactly the ones with large seat counts that would make per-MAU pricing punishing.

The practical read: if your enterprise customers are large organizations, per-connection pricing is dramatically cheaper than paying per user for those same thousands of employees. If your customers are small teams, the calculus shifts and a per-MAU tool may cost less.

WorkOS vs Auth0 vs Clerk vs Stytch

The decision usually comes down to what you already have.

If your authentication works and you only need enterprise SSO and provisioning, WorkOS is the cleanest fit. It bolts onto what exists, prices per connection, and does not ask you to migrate your login system. This is its home turf and the reason it appears so often as the answer to a single enterprise deal.

If you are choosing authentication from scratch, a full platform like Stytch or Clerk may serve better, because it gives you consumer auth and enterprise features in one system rather than two. Running WorkOS purely for SSO alongside a separate auth system is common and reasonable, but it is two systems.

If you are already on Auth0 and hitting its enterprise pricing, WorkOS frequently appears in migration stories specifically for the SSO portion, because the per-connection model can be far cheaper for a business selling to large organizations.

The Enterprise Checklist, and When Each Item Matters

Enterprise deals fail on a predictable list of requirements. Knowing when each becomes a blocker helps you sequence the work.

SAML SSO is almost always the first hard requirement. Enterprises want their employees logging in through their own identity provider, not creating separate passwords in your app. This is usually the item that appears in the first security review and stalls the deal.

Directory Sync (SCIM) follows closely. When an enterprise offboards an employee, that person must lose access to your product automatically, without your customer filing a support ticket. Security teams treat manual deprovisioning as a serious risk, and SCIM is how you satisfy them.

Audit Logs become mandatory for customers in regulated industries or those pursuing their own compliance certifications. They need a record of who did what and when, exportable to their security tooling.

Role-based access control matters once a customer's organization is large enough to need different permission levels for different employees.

The sequence is usually SSO first, then SCIM, then audit logs, each triggered by a larger or more regulated customer than the last. Building them in that order, driven by real deals rather than speculation, is the efficient path.

Why Building SSO Yourself Goes Wrong

Teams routinely estimate SAML at a week and are surprised. The reason is that SAML is not one integration, it is a family of subtly incompatible ones.

The specification is old, loosely interpreted, and implemented differently by each identity provider. Okta, Microsoft Entra, and the dozens of smaller providers each have their own quirks in how they format assertions, handle metadata, and expect the exchange to flow. Building against one and assuming the rest will follow is the mistake that turns a week into a quarter, because the second customer uses a provider that behaves differently and the third breaks an assumption you did not know you had made.

Then there is the security surface. Authentication is the one part of your system where a subtle bug is a serious vulnerability rather than an inconvenience. SAML has well-known implementation pitfalls, signature validation, assertion replay, XML parsing, that are easy to get wrong and catastrophic when you do. This is specialized security work, not general application development.

And once built, it needs maintaining forever. Identity providers change, new ones appear, and each becomes your problem in perpetuity. A platform absorbs that ongoing burden, which is often worth more than the initial time saved.

The honest calculation is not the cost of building SSO once. It is the cost of building it, securing it correctly, supporting every customer's identity provider, and maintaining all of it indefinitely, against a per-connection fee that scales with the revenue those connections bring in. For almost every startup, buying wins until you have a specific reason it does not.

Who Should Use WorkOS?

Use it if you sell B2B SaaS, your product has working authentication, and enterprise customers are asking for SSO, SCIM, or audit logs. This is exactly the situation WorkOS is built for, and adding it is a matter of days rather than the weeks a from-scratch SAML implementation takes.

Use it if a specific enterprise deal is blocked on a security requirement. The credits and the fast integration mean you can turn a blocking requirement into a resolved one inside a sales cycle rather than a roadmap quarter.

Look elsewhere if you are building a consumer product with no enterprise customers, where per-connection SSO pricing is irrelevant and a per-MAU auth platform fits better. Also reconsider if you are choosing your entire authentication stack fresh, where a single full-featured platform may be simpler than combining two systems.

Real Startup Use Cases

A B2B SaaS company had a six-figure deal contingent on SAML SSO that did not exist in the product. Building it against multiple identity providers correctly was estimated at several weeks. Through WorkOS the team shipped SSO in days, the security review passed, and the deal closed within the original sales cycle. The credit covered the connection while the contract was still being signed.

A growing platform kept losing enterprise prospects at the offboarding question, because access removal was manual and security teams flagged it. Adding Directory Sync meant deprovisioning happened automatically when a customer removed an employee, which turned a recurring objection into a checkbox.

A company selling into regulated industries needed exportable audit logs for customers pursuing their own compliance. Adding the audit log product let those customers satisfy their auditors using data from your platform, removing a barrier that had been disqualifying you from an entire segment.

How to Claim the Credits

1. Follow the link on this page to WorkOS and create an account.
2. Apply the credits in billing and confirm the balance.
3. Start with the product a real deal needs, usually SSO, rather than integrating everything speculatively.
4. Use the test environment and a sample identity provider to integrate end to end before touching a customer.
5. Set up the Admin Portal so your customers' IT teams can self-configure, which removes you from the middle of every setup.
6. Add SCIM and audit logs when specific customers require them, not before.

Tips for a Clean Integration

1. Let customers self-serve through the Admin Portal. Configuring SAML by trading metadata files over email is painful for everyone. The hosted portal lets the customer's IT admin do it themselves, which scales far better as you add enterprise accounts.
2. Integrate SSO before you need it urgently. Doing it under deal pressure, against a deadline, is how mistakes happen. If enterprise is on your roadmap, build SSO ahead of the deal that demands it.
3. Price the connection before you quote the customer. A connection needing both SSO and SCIM costs roughly double the SSO figure. Know your cost so enterprise pricing covers it.
4. Keep the enterprise layer separate from core auth. Treat WorkOS as the enterprise-readiness layer over your existing authentication rather than entangling the two, which keeps both easier to reason about and to change.
5. Test deprovisioning specifically. SCIM removing access is the flow security teams care about most, and the one most likely to be misconfigured. Verify that removing a user on the identity provider actually revokes access in your app.
6. Track connections against your credit. Per-connection billing is predictable, which means you can forecast exactly when the credit runs out and ensure enterprise revenue has arrived by then.

Who Is This Deal For?

Frequently Asked Questions

Everything you need to know about this startup deal.