A practical guide to identity and OAuth for business integrations

Your webshop sends an order. Your ERP never receives it. Somewhere between two systems that were never introduced to each other, a staff member opens a spreadsheet and starts typing. This happens dozens of times a day in companies that have grown faster than their software — and the root cause is almost always the same: systems that cannot securely prove who they are to each other. This article explains how identity and OAuth work in practice, what breaks in real integrations, and how to get it right the first time.

Why do business integrations fail at the authentication step?

Most integration projects start with enthusiasm about data flows and end in frustration over login errors, expired tokens, and permission denied responses. The reason is that authentication — the process of systems proving their identity to each other — is treated as an afterthought rather than a foundation.

When a developer connects FileMaker to Exact Online, for example, the first question is not "what data do we sync?" It is "how does FileMaker prove to Exact Online that it has the right to request that data?" Get that wrong, and nothing else matters.

What is OAuth, and why does every modern API use it?

OAuth 2.0 is the open standard that most modern APIs — including Exact Online, Microsoft 365, Google Workspace, Shopify, and hundreds of others — use to handle authorization between systems. It is not a login system. It is a delegation protocol: it allows one system to act on behalf of a user or business, without that system ever seeing the user's password.

Here is what actually happens when your webshop connects to your ERP using OAuth:

1. Authorization request — Your webshop sends the user to the ERP's login page, with a request specifying what access it needs (called a scope, e.g. "read orders, write invoices").
2. User consent — The business owner logs in at the ERP and approves the requested permissions.
3. Authorization code — The ERP redirects back to your webshop with a short-lived code.
4. Token exchange — Your webshop's server exchanges that code (plus its own client secret) for an access token and a refresh token.
5. API calls — Every subsequent API request carries the access token in its header. No passwords are ever transmitted.
6. Token refresh — Access tokens expire (often after one hour). The refresh token is used to get a new one automatically, without user involvement.

This flow is called the Authorization Code Grant and is the correct flow for server-side business integrations. It is important to distinguish it from other OAuth flows — the Client Credentials Grant (machine-to-machine, no user involved) and the Implicit Grant (deprecated, do not use) — because choosing the wrong flow is one of the most common integration mistakes.

What is the difference between authentication and authorization?

These terms are often used interchangeably in conversation but they mean different things in code:

• Authentication (AuthN) = proving who you are ("I am the Loggix FileMaker server")
• Authorization (AuthZ) = proving what you are allowed to do ("I am allowed to read this company's sales invoices")

OAuth handles authorization. For authentication of the system itself, you typically also need a client ID and client secret — credentials that identify your integration application to the API provider. Think of client ID as a username and client secret as a password for the application itself, separate from any end user.

In a FileMaker-to-Exact Online integration, both are in play: the FileMaker server authenticates itself with its client credentials, and the OAuth token proves it is authorized to access a specific Exact Online division on behalf of a specific company.

What goes wrong in real integrations — and why?

After building integrations between FileMaker, Exact Online, webshops, and various ERPs, the same failure patterns appear repeatedly:

1. Hardcoded credentials A developer stores the client secret directly in a script or configuration file. Six months later, the secret is rotated (or the file is accidentally shared), and the integration silently stops working. The fix: store secrets in a secure vault or environment variable, never in source code.

2. Token expiry not handled An order gets entered into FileMaker at 8:00 AM. The sync runs fine. The same order is updated at 10:30 AM — but the access token expired at 9:00 AM and the refresh logic was never implemented. The update fails silently, and no one notices until a customer calls about a wrong invoice. The fix: always implement refresh token logic, and log every token exchange with a timestamp.

3. Scope creep in the wrong direction To avoid permission errors during testing, a developer requests maximum scopes (full read/write access to everything). The integration goes live with those scopes. Now a bug in the sync script can overwrite financial records it was never supposed to touch. The fix: request the minimum scopes needed, and review them before go-live.

4. Single-user OAuth tokens The integration is authorized with the personal account of the IT manager. When that person leaves the company, their account is deactivated, and every integration breaks simultaneously — often over a weekend. The fix: always authorize integrations using a dedicated service account, not a personal user account.

5. Missing state parameter OAuth requires a state parameter during the authorization request to prevent Cross-Site Request Forgery (CSRF) attacks. Many custom integrations skip it during prototyping and never add it. The fix: generate a random state value, store it in session, and validate it on the callback.

How does this work specifically with Exact Online?

Exact Online uses a standard OAuth 2.0 Authorization Code flow with a few specifics worth knowing:

• Division-based access: Exact Online organizes data by division (roughly equivalent to a company or subsidiary). Your access token is scoped to a specific division. If a client has multiple divisions, you need to handle division switching explicitly.
• Token lifetime: Access tokens are valid for 10 minutes. Refresh tokens are valid for 30 days but rotate on each use — meaning you must save the new refresh token every time you refresh, or you will permanently lose access.
• Rate limits: Exact Online enforces rate limits per API key. In a busy FileMaker integration that syncs orders, stock, and invoices, it is easy to hit these limits if sync scripts run too aggressively. Implement exponential backoff and queue management.
• Webhook limitations: Exact Online's webhook support is limited compared to platforms like Shopify. For near-real-time sync, you often need to poll on a schedule — which makes token management and rate limiting even more important.

How do you connect a webshop to an ERP without breaking every night?

A webshop-to-ERP integration is one of the most common and most fragile integrations in practice. An order comes in via Shopify, WooCommerce, or a custom webshop. That order needs to appear in the ERP (as a sales order or invoice), and stock levels from the ERP need to flow back to the webshop. Every step involves an authenticated API call.

Here is the architecture that works reliably:

1. Webshop webhook triggers on new order — instead of polling, the webshop pushes a notification the moment an order is placed.
2. Middleware receives and queues the event — a middleware layer (FileMaker server script, a Node.js service, or a dedicated integration platform) receives the webhook, validates its signature (webhooks have their own authentication — a shared secret in the header), and places the order in a processing queue.
3. Middleware authenticates to ERP using OAuth — the middleware uses a stored, auto-refreshed access token to call the ERP API and create the order.
4. ERP confirms creation — the middleware stores the ERP order ID mapped to the webshop order ID, so future updates (shipment, cancellation) can reference the correct record.
5. Stock sync runs on schedule — stock levels are polled from the ERP every 15 minutes and pushed to the webshop's inventory API, again using OAuth tokens for both.

The most important insight here: the middleware is not optional. Trying to connect a webshop directly to an ERP without a stateful layer in between means there is nowhere to handle token refresh, retry logic, error logging, or mapping conflicts.

Where does AI fit into an automated business workflow?

Once data flows reliably between systems, AI becomes practically useful — not as a chatbot layer on top, but as a processing step inside the workflow itself.

A concrete example: A customer emails a complaint about an order. Instead of a staff member reading the email, looking up the order in FileMaker, checking the invoice in Exact Online, and drafting a reply — the workflow does this:

1. Email arrives → parsed by an AI model (e.g. via OpenAI API) to extract order number, issue type, and sentiment.
2. FileMaker receives the structured data → looks up the order record automatically.
3. If the issue matches a known resolution pattern → a draft response is generated and queued for one-click approval.
4. If not → the ticket is flagged with priority and routed to the right team member with context already filled in.

This is AI as a workflow step, authenticated via API key (OpenAI uses API key authentication rather than OAuth, but the principle of secure credential storage and scoped access is identical). The value is not the AI itself — it is the AI embedded in a workflow where identity and data access have already been solved correctly.

Integration identity checklist — before you go live

Before any integration between business systems goes into production, run through this checklist:

• OAuth flow type matches the use case (Authorization Code for user-delegated access, Client Credentials for machine-to-machine)
• Client ID and secret stored securely (environment variable or vault, never in source code or FileMaker data viewer)
• Dedicated service account used for OAuth authorization (not a personal user account)
• Refresh token logic implemented and tested (simulate an expired access token before go-live)
• Token storage is persistent and encrypted (refresh tokens are long-lived credentials — treat them like passwords)
• state parameter implemented in OAuth callback to prevent CSRF
• Minimum required scopes requested (document which scopes are used and why)
• Error handling logs authentication failures with timestamps and HTTP status codes
• Rate limit handling implemented (retry with backoff on 429 responses)
• Webhook signature validation implemented (if webhooks are used)
• Runbook documented: what to do if the integration stops authenticating

Frequently asked questions

Do I need OAuth if I'm just connecting two internal systems? Not necessarily. If both systems are under your control and never expose data to the internet, API key authentication or mutual TLS may be simpler and sufficient. OAuth adds the most value when a third-party SaaS platform (Exact Online, Shopify, Microsoft 365) is involved and you need to act on behalf of a specific user or company.

What is the difference between an API key and an OAuth token? An API key is a static credential that grants access to an API — it does not expire and is not scoped to a specific user. An OAuth access token is dynamic, short-lived, and represents delegated access on behalf of a specific account. API keys are simpler but riskier if leaked. OAuth tokens are more complex to implement but safer and more auditable.

Can FileMaker handle OAuth natively? FileMaker can initiate OAuth flows using its Open URL script step and receive callbacks via a custom web viewer or a local redirect URL. Token storage and refresh logic need to be built as FileMaker scripts or handled by a middleware layer. For complex integrations, a dedicated middleware service alongside FileMaker is more maintainable than doing everything inside FileMaker scripts.

How often do refresh tokens expire? It depends on the platform. Exact Online refresh tokens expire after 30 days of non-use and rotate on each use. Microsoft 365 refresh tokens can last up to 90 days. Shopify's offline access tokens do not expire unless revoked. Always check the specific platform's documentation and build expiry alerts into your monitoring.

What happens if a refresh token is lost? The integration loses access permanently until a user re-authorizes it through the full OAuth flow again. This is why refresh token storage must be treated with the same seriousness as a password. Back them up, encrypt them at rest, and monitor for unexpected expiry.

Is OAuth 1.0 still relevant? Rarely. OAuth 1.0 required complex request signing and has been superseded by OAuth 2.0 in virtually every modern API. The only reason to encounter it today is when integrating with legacy platforms that have not been updated. Avoid it in new builds.

---

Getting authentication right is the unglamorous prerequisite for everything else in a business integration — the data flows, the automation logic, the AI steps. If you are building or modernizing integrations between systems like FileMaker, Exact Online, a webshop, or any other platform in your stack, Loggix can help you design the authentication architecture correctly from the start, build the middleware layer that keeps tokens alive and errors visible, and connect AI-powered steps where they genuinely reduce manual work. The result is not just systems that talk to each other — it is a business that stops re-typing the same data every single day.