How do you handle user offboarding at scale? Is the API or IdP sync faster?

That sync latency question is exactly where theory meets reality. In our setup with Azure AD, we've observed the group sync itself is reasonably fast, often within a few minutes. The real delay, and the compliance risk, enters during the provisioning cycle window you configure in the Twingate connector.

If you have it set to run hourly, you've potentially got a 59-minute gap between the IdP change and Twingate acting on it. For a true offboarding event, that's an unacceptable window for us. We combated this by using the Twingate API as a failsafe.

We have our identity automation workflow call the Twingate API's `user delete` endpoint directly as a final step, after removing the user from all IdP groups. This gives us an immediate revocation logged in our SIEM, and then the connector's sync later just cleans up the orphaned record. It adds a dependency, but it closes the time gap completely. The API call is faster than waiting for any sync schedule.

Your skepticism about IdP sync latency is spot on. The connector's polling interval is the bottleneck, not the sync itself. Relying solely on it means accepting that built-in delay window.

We use a hybrid model. The IdP group sync handles the bulk cleanup over time, but our automated offboarding workflow calls the Twingate API directly for immediate revocation. This gives us an audit trail with a precise timestamp for compliance, independent of the connector's cycle.

The API is faster for the initial kill, full stop. But you need the IdP sync to keep things clean and handle edge cases like group reassignments. One without the other leaves a gap.

The sync latency you're asking about is the key operational variable. It isn't immediate; it's a function of the polling interval you configure on your Twingate connector. A typical interval is 5 to 15 minutes, but many teams set it to hourly for performance reasons, which introduces that exact risk window.

While user29 mentioned using the API as a failsafe, you can actually invert that model for more deterministic control. We trigger the API call to suspend the user *first*, directly from our HR system webhook, as the earliest step in the termination workflow. This gives us a sub-10-second revocation. The IdP group removal and subsequent connector sync then happen later, serving as a cleanup and validation step. This way, the IdP sync's latency becomes irrelevant for the primary security objective.

You still need the IdP sync running, though. It handles the scenario where a user is moved between groups rather than fully terminated, and it acts as a reconciliation mechanism if the API call were to fail. The API is for speed; the IdP sync is for eventual consistency and system hygiene.

Your point about inverting the model and making the API call the primary action is a critical operational refinement. It flips the risk from the polling interval to the reliability of your own automation, which is far more controllable.

However, this approach necessitates a more robust error-handling and retry logic in your workflow than the IdP sync provides. If your HR webhook fails to call the Twingate API, you have zero safety net until the next connector sync, which could be an hour later. You're essentially trading one latency window for a potential failure mode.

We mitigate this by implementing the API call with an exponential backoff retry, and we still log the termination event to a queue that the IdP sync process also consumes. This gives us the immediate revocation *and* a guaranteed, albeit slower, fallback path through the connector if our primary automation fails three times.

That last point about a queue as a shared state between the API-driven and sync-driven paths is a solid architectural pattern. It effectively decouples the immediate revocation intent from the eventual system-of-record cleanup.

One nuance I've encountered is that the API call and the subsequent IdP sync can, in a narrow edge case, create a race condition if the user is removed from all groups but the connector hasn't yet processed that. If the API deletes the user and then minutes later the connector runs and sees "user not in any synced groups," it might attempt to delete a now non-existent resource. This typically results in a harmless 404 in the connector logs, but you need to ensure your alerting on connector errors is tuned to ignore this specific case to avoid alert fatigue.

Your dual-path model with a queue addresses this elegantly, as you can deduplicate events. We achieved something similar by having our automation script set a custom user attribute in the IdP (like `terminationTimestamp`) before calling the API. The connector is configured to exclude users with that attribute from its sync operations, preventing any conflict.

The custom attribute trick is clever, but it introduces a new state you have to manage. What happens when someone manually clears that attribute, or your connector's filter logic has a typo? You've now got a stale, active account.

I'd argue the 404 noise from the race condition is the lesser evil. You can mute alerts for that specific pattern far more reliably than you can guarantee the hygiene of a custom field that sits outside the primary offboarding workflow.

Your queue model is better, but if you're going that far, just make the queue the single source of truth. Let the API call and the connector sync both be idempotent consumers. That way, a duplicate event is just a no-op, and you don't need filter gymnastics.

I agree that making the queue the single source of truth is the superior architecture, but your point about the 404 being a "lesser evil" requires a hard look at your actual logging pipeline.

You can only mute those alerts reliably if your connector logs are structured consistently and ingested into a system where you can create a precise suppression rule. In our setup, the Terraform Cloud agent that manages the connector logs in JSON, but the 404 error from the race condition doesn't have a unique, stable identifier you can key off. You end up writing a fuzzy match on the error message string, which is brittle across connector updates.

The safer pattern is to have your API consumer check for existence before deletion, or to structure the offboarding event in the queue so the sync consumer knows it's handling a post-deletion cleanup and skips the delete call entirely. This adds a few lines of logic but removes the alert noise altogether without relying on log parsing.

The custom attribute filter is a clever workaround, but it shifts the management burden to your IdP's schema and adds another point of potential misconfiguration. If that attribute doesn't sync correctly, you've broken the entire safety net.

The race condition 404 is indeed harmless, but as others have noted, managing the alert noise is a real ops overhead. A better implementation of your queue idea is to have the sync process check the queue state before acting on a user it sees as "orphaned." If an API deletion event exists in the queue for that user, the connector skips the operation entirely, preventing the log error at its source.

You're right that moving the check into the sync process is cleaner than trying to filter logs. But that requires modifying the connector's logic, which isn't always possible with off-the-shelf SaaS connectors.

A more deployable version of your idea is to have the sync process write the "orphaned" user ID to a staging table first. A separate, idempotent cleanup job then reads from that table, checks against the queue's state, and performs the actual deletion via the API. This keeps the core connector untouched and pushes the de-duplication logic to a system you fully control.

You've zeroed in on the core problem: the sync latency is the entire ballgame. The observed sync time isn't "immediate" - it's the polling interval plus processing time. A vendor saying "real-time sync" is technically correct if you define your interval as 5 minutes, but that's a 5-minute window of risk, which is unacceptable.

I've benchmarked this. With a standard hourly sync, the 95th percentile latency from group removal to Twingate deprovisioning was 64 minutes in our setup. That's not a tool problem, it's a default configuration problem you have to engineer around.

So no, you cannot rely solely on IdP sync for deterministic offboarding. The API is orders of magnitude faster for the critical initial revocation, but it creates a separate problem of orchestration, as the later posts in this thread correctly explore.

Your point about the sync process checking the queue state is architecturally sound, but you're adding a read dependency and a new failure mode to the sync path. Now the connector's ability to clean up orphans is gated on the availability and low latency of your queue service. If that queue check times out, your failure mode is either a false positive deletion attempt or a stalled cleanup, both of which require their own handling.

The more deterministic, albeit heavier, solution is to make the queue the write-ahead log. The API call consumes the event and performs the deletion, then posts a confirmation back to the queue. The sync process, upon seeing a user not in any groups, only acts if there is *no* deletion confirmation for that user ID within a defined lookback period. This adds a delay to the IdP cleanup but removes the critical path dependency.

The observed sync latency is the deciding factor, and it's never immediate. You can't treat an hourly polling job as a revocation mechanism. It's a cleanup mechanism.

So the real process is two-phase: API call for immediate kill, IdP sync for eventual cleanup. Anything else leaves a window measured in minutes, not seconds.

That means your actual scale process is an automated workflow calling the Twingate API, triggered directly from your HR system. The IdP sync is just there to mop up if your automation misses something.