For the people who need the exact mechanics
This is the technical-reviewer depth behind /integrations: how The Forge sits between your systems, which system keeps the official record for each type of information, exactly what happens when a connection fails, and how bidirectional sync avoids duplicate or conflicting records.
What happens between the moment something changes and the moment it shows up.
Every connection follows the same shape: a source event, a trigger, a validation step, and a destination update. When validation fails, The Forge holds the record and retries — it does not drop it or send it twice.
- Validation failed — A required field is missing or the record can't be matched. The update is held, not dropped.
- Retry scheduled — The Forge retries on a safe schedule and notifies the owner if the problem does not clear.
Architecture — how The Forge sits between your systems
The Forge does not just move individual fields between applications. It keeps the connected information — the customer, the invoice, the employee, the location, the campaign — together, so automation and reporting work from one connected record instead of a stack of separate exports.
- 1
External systems
Payroll, POS, accounting, CRM, comms, industry tools.
- 2
Authentication + connection
OAuth, scoped tokens, signed webhooks.
- 3
Validation + data mapping
Field mapping, identity matching, duplicate protection.
- 4
Forge operational record
Customer, work, employee, communication, financial context.
- 5
Workflow + approvals
Rules, ownership, human-approval gates on sensitive actions.
- 6
Role-based actions
The right person sees the right action for the current task.
- 7
Reporting, monitoring, audit
Health, failures, retries, credential health.
- 8
Approved updates back out
Only what was reviewed, only where it belongs.
Setup classifications
Every published integration carries a status. We do not label a connection “available” if it is only conceptual or on the roadmap.
Which system keeps the official record for each type of information
The Forge connects your systems without taking over the records they are responsible for. Your accounting software remains the official financial record, payroll stays with your payroll provider, and regulated systems keep the official record for what they hold. The Forge keeps the official record for the connected workflow, responsibility, escalation, and reporting around them.
- General ledger, invoicing, paymentsAccounting system
- Processed payroll, tax filingsPayroll provider
- Clinical records, patient chartsPractice-management system
- Policy records, carrier dataAgency-management system
- Regulated student recordsStudent information system
- Day-to-day workflow, assignments, escalationThe Forge
- Reporting across systems and what managers can seeThe Forge
- Communication history threaded across channelsThe Forge
What happens, step by step, when a connection has a problem
If a connection goes down, The Forge holds and safely retries anything already approved — it will not lose work or send duplicate records. Here is the exact behavior for each failure type.
External provider is temporarily unavailable
A third-party API stops responding or returns 5xx errors.
- Preserve the approved operation — nothing is lost.
- Queue eligible actions for retry on policy.
- Record the failure with timestamp and cause.
- Retry with exponential backoff up to the configured window.
- Notify the appropriate owner if the outage crosses the alert threshold.
- Prevent duplicate creation when the provider comes back.
- Escalate unresolved items after the retry window closes.
Authentication expires
An OAuth token or API key stops being accepted.
- Detect the rejected request on the first 401 / 403.
- Pause unsafe writes to the affected provider.
- Notify the technical owner with the specific credential and provider.
- Preserve pending actions until credentials are restored.
- Resume only after re-authorization is confirmed.
- Record the outage and the recovery in the audit history.
Partial synchronization
A batch of records completes for some and fails for others.
- Identify which specific records succeeded and which failed.
- Avoid repeating completed operations on retry.
- Assign failed records for review with the specific reason.
- Preserve the audit trail linking source and destination IDs.
- Reflect incomplete status on the dashboard until reviewed.
Bidirectional sync — conflict rules and duplicate-event handling
When information can move in both directions, we decide in advance which system keeps the official record for each type of information — so a conflict has one predictable outcome.
- Every bidirectional connection has an explicit conflict policy, documented per data domain — the workflow pages show real examples.
- Idempotency keys and provider-supplied event identifiers prevent a retried webhook or replayed batch from creating a duplicate record.
- Provider rate limits are honored; requests queue and retry rather than fail outright.
- Full credential, permission, API, webhook, and audit detail lives on the integration security page.
Know when a connection needs attention.
An integration is not complete unless it can be watched, controlled, and fixed. Every connection reports whether it's working, tracks credential expiration, records failures, retries safe operations, and routes unresolved problems to a named owner.
Whether connections are working
- ConnectedThe connection is healthy and events are flowing at expected volume.
- SynchronizingA batch of records is currently being sent or received. Normal for scheduled syncs.
- DelayedEvents are flowing but slower than the expected frequency. The Forge is monitoring; no action required yet.
- Action RequiredA record needs human review — usually a mapping decision, a duplicate to resolve, or an approval to release.
- Credential ExpiringA login credential will expire soon. The Forge reminds the technical contact to renew it before it causes a problem.
- Provider UnavailableThe third-party provider is not accepting requests. Approved actions are queued; no duplicates will be sent.
- Rate LimitedThe provider is limiting how many requests it will accept right now. The Forge waits and tries again safely.
- Partial FailureSome records succeeded and some failed. Successful records are complete; failed records are assigned for review.
- DisabledThe customer or an administrator has paused the integration. No traffic flows in either direction.
- Under MaintenanceA planned upgrade or reconfiguration is in progress. The customer is notified in advance.
We do not promise uninterrupted availability when The Forge depends on external providers. We promise a problem will be visible, recoverable, and traceable — not silent.
- Architecture and data-ownership walkthrough for your stack
- Exact failure and retry behavior for each proposed connection
- Bidirectional sync rules defined before anything is built
- A named technical owner for every connection