How to revoke access to an integration safely

An employee who set up your Exact Online connector leaves the company on Friday. By Monday, their personal OAuth token is still live, still pulling financial data, and nobody on your team knows it exists. Or a third-party agency finished a project six months ago, but the API key they used never got deleted — and it still has write access to your production environment.

These are not edge cases. They are the default outcome when access revocation is treated as an afterthought rather than a planned step. This article walks you through exactly how to revoke API keys, OAuth tokens, and integration permissions safely — without breaking the live systems that depend on them.

Why stale credentials are a bigger risk than most teams realize

Most security conversations focus on who gets access. Far fewer focus on what happens when that access should end. The result is a slow accumulation of "ghost credentials" — tokens and keys that are technically valid but no longer have a legitimate owner.

A concrete example: a developer connects FileMaker to Exact Online using OAuth 2.0. The OAuth flow is tied to their personal Exact Online account. They leave the company. HR disables their Active Directory account — but the OAuth token issued to the FileMaker integration lives independently of that account until it is explicitly revoked. Depending on the token's expiry and refresh logic, it can remain functional for weeks or indefinitely.

The same problem appears with API keys. An API key issued to a webhook integration has no expiry by default in most platforms. Unless someone manually deletes it, it persists. And because API keys are often stored in config files or environment variables rather than a password manager, they are easy to lose track of.

What is the difference between revoking an OAuth token and deleting an API key?

Understanding the technical difference matters, because the revocation path is different for each.

OAuth 2.0 tokens follow the RFC 7009 revocation standard. A token consists of two parts: an access token (short-lived, typically 1 hour) and a refresh token (long-lived, used to get new access tokens silently). Revoking the refresh token is the critical step — it cuts off the integration's ability to renew its own access. Simply waiting for the access token to expire is not enough, because if the refresh token is still valid, the integration will just request a new access token automatically.

To fully revoke OAuth access:

1. Send a revocation request to the authorization server's /revoke endpoint with the refresh token.
2. If the platform supports it (Exact Online does), also revoke via the platform's own admin UI — this is the safest double-confirmation.
3. Remove the stored tokens from wherever your application keeps them (FileMaker data fields, a secure vault, environment variables).

API keys do not have a revocation endpoint in the OAuth sense — they are simply deleted or disabled in the issuing platform's admin console. The revocation is immediate and permanent. The practical risk here is that the key may be hardcoded somewhere (a FileMaker script, a server-side data source definition, a cron job) and deleting it will break those integrations instantly without warning.

How do you revoke access without breaking a live integration?

This is the question most guides skip. Revoking credentials that an active process still depends on causes outages. The safe approach is to rotate first, then revoke — not the other way around.

The rotation-before-revocation pattern:

1. Identify all places the credential is used. Before touching anything, audit where the key or token is referenced. For a FileMaker ↔ Exact Online integration, that means checking FileMaker scripts, data source configurations, scheduled server scripts, and any middleware layer (like a REST API connector or MBS plugin configuration).
2. Create a new credential. Issue a new API key or trigger a fresh OAuth authorization flow under a service account (not a personal account — more on this below). Confirm the new credential works end-to-end in a test or staging environment first.
3. Swap the credential everywhere it is used. Update every reference — FileMaker scripts, config records, environment variables — to use the new credential. Deploy and verify.
4. Revoke the old credential. Only now, once the new credential is confirmed working in production, delete or revoke the old one.
5. Verify the revocation. Attempt a test call using the old credential and confirm it returns a 401 Unauthorized response. Do not assume revocation worked — confirm it.

Should integrations ever use a personal account's OAuth token?

No — and this is one of the most common mistakes in smaller businesses. When a developer or power user sets up an OAuth-based integration using their own account, the token is bound to their identity. The moment they leave, you face an immediate choice: revoke it and break the integration, or leave it running under a departed employee's credentials.

The correct approach is to use a dedicated service account — a non-personal account created specifically for the integration, with only the permissions the integration actually needs. In Exact Online, this means a separate user seat provisioned as an integration account, with scoped permissions (read-only to financial data, for example, rather than full admin access).

For REST APIs that use API keys rather than OAuth, the key should be generated under a team or system owner, not an individual. Most modern platforms (GitHub, Stripe, SendGrid) now support organization-level API keys or service tokens precisely for this reason.

Using service accounts means that when a person leaves, you are offboarding a human — not also emergency-decommissioning an integration.

What should an access revocation checklist look like?

Here is a practical checklist to run through whenever an employee leaves or an integration is decommissioned:

Before revoking:

• Identify every integration the person set up or owns
• Map all credentials (OAuth tokens, API keys, webhook secrets) associated with them
• Determine whether each integration is still in active use
• For active integrations: prepare replacement credentials under a service account
• For decommissioned integrations: confirm with the business owner that the integration can be switched off

During revocation:

• Rotate credentials for active integrations before revoking old ones
• Revoke OAuth refresh tokens via the platform's admin console and/or revocation endpoint
• Delete API keys in the issuing platform (Exact Online, the REST API provider, etc.)
• Remove stored credentials from FileMaker fields, scripts, environment variables, and config files
• Revoke any connected app authorizations in the OAuth provider's admin panel

After revoking:

• Test that revoked credentials return 401 Unauthorized
• Confirm active integrations running on new credentials are functioning normally
• Update your integration inventory/documentation to reflect the change
• Log the revocation event (date, credential type, system affected, revoked by whom)

How do you keep track of all your active integrations in the first place?

You cannot revoke what you cannot find. Most businesses that struggle with credential hygiene do not have a rogue developer — they just have no integration inventory. Over time, integrations get added by different people, using different accounts, and nobody maintains a central record.

A basic integration register does not need to be sophisticated. A spreadsheet or a table in your internal system with the following columns is enough to start:

• Integration name (e.g., FileMaker → Exact Online invoice sync)
• Credential type (OAuth / API key / webhook secret)
• Credential owner (service account name, not a person's name)
• Platform where credential is issued (Exact Online admin > OAuth apps)
• Systems it connects (FileMaker + Exact Online)
• Who set it up and when
• Last verified working date
• Status (active / decommissioned / under review)

This register becomes the starting point for every offboarding process and every security review.

What happens if you revoke a token and something breaks unexpectedly?

Despite careful preparation, things break. A FileMaker server script you forgot about suddenly starts logging authentication errors. A nightly sync to Exact Online fails silently and you only notice three days later when invoices are missing.

Have a rollback plan before you revoke:

• Keep the old credential in a secure location (not deleted yet) for a 24-48 hour window after cutting over to the new one, so you can reinstate it quickly if needed.
• Set up monitoring or alerting on the integration's output — a failed sync should generate a visible error, not a silent gap in data.
• For FileMaker-based integrations, check the FileMaker Server log and any custom error-logging scripts for authentication failures in the hours following the revocation.

Once you are confident the new credential is stable, then permanently delete the old one.

FAQ

Does disabling a user's Active Directory or SSO account automatically revoke their OAuth tokens? No, not in most cases. OAuth tokens issued to third-party applications (like a FileMaker integration connecting to Exact Online) are independent of the user's login session. Disabling the account prevents the person from logging in, but does not automatically invalidate tokens already issued. You need to explicitly revoke them in the OAuth provider's admin console.

How long does it take for a revoked OAuth token to stop working? An access token revocation via the /revoke endpoint takes effect immediately on platforms that support RFC 7009. However, if your integration is caching the access token locally and not checking validity on each request, it may continue to work until the cache expires. Always test post-revocation with a live API call to confirm.

Can I set expiry dates on API keys to avoid this problem? Many platforms now support expiring API keys (GitHub, for example, strongly encourages short-lived tokens). Where this option exists, use it — a 90-day or 1-year expiry forces a regular rotation cycle and limits the damage window of a forgotten credential. Exact Online's OAuth tokens use short-lived access tokens with refresh tokens, which is a better model than non-expiring API keys.

What if the person who set up the integration is no longer available to help with the transition? This is exactly why service accounts and an integration register matter. If the integration runs under a service account that your team controls, the departing person's absence is irrelevant — you already have the credentials. If it runs under their personal account and they are gone, you may need to contact the API provider directly to revoke the OAuth application authorization from the admin side, or force-expire credentials through the platform's admin tools.

Is token revocation the same as deleting the OAuth application? No. Deleting (or deregistering) the OAuth application in the provider's developer console will invalidate all tokens issued to that application, which is a more nuclear option. Revoking a specific token only invalidates that token. Use application deletion when you are fully decommissioning an integration; use token revocation when you are rotating credentials or offboarding one user but keeping the integration running.

---

If your business relies on integrations between FileMaker and external platforms like Exact Online — or between any combination of REST APIs — the moment to build a clean credential management process is before the next person leaves, not after. Loggix helps businesses design and build integrations that are secure by default: using service accounts, scoped permissions, token rotation, and audit logging from the start. Whether you need to untangle an existing integration setup, connect systems through well-structured API connectors, or get hands-on consultancy to map out a safer integration architecture, we're happy to think through the next step with you.