How Integration Core works
Integration Core help · for everyone · graded against Core v1.0.0-rc.5 · written 2026-10-06 · re-read against rc.8's screens 2026-10-09 · where a newer Core words a screen differently, see the Glossary's "Changed in newer releases"
What this page restates, and from where: the support runbook §2, §3, §3b, §5, §6 and §9 (2026-09-13, re-looked-up 2026-10-02); the setup guide, Steps 1, 5, 6 and 7 and Getting alerts by email (screens re-derived 2026-09-27); What Integration Core gives you today (2026-09-13, release rows 2026-10-02); the install guide §1 and §7 (2026-10-02). Each section ends with its source line. Where this page and a paper disagree, report it; a section that read a newer build than its paper says so.
What Integration Core is, and what it is not
Integration Core is the shared half of every iVendNext integration. It syncs nothing by itself. It is the record of every change that crosses, the links between iVendNext's records and the other system's, the position each sync has reached, the safety rules, and one screen — the Integrations Hub — that an operator watches whatever system they connect.
What actually crosses is the connector's: one connector per system (WooCommerce, Acumatica, …), each with its own setup page, its own credentials and its own description of what it syncs. Where a connector's page and Core's disagree about that platform, the connector's is right.
⭐ Integration Core makes no outbound network call, ever. That is enforced in its build, not promised. So it needs nothing opened on a firewall, and it cannot become a hub that routes one system into another. Connectors never call each other either: each one reads and writes the iVendNext document, which is the meeting point.
Connecting a second system adds no new queue, no second monitor and no second Retry button — only its own setup page.
Source: What Integration Core gives you today, the opening and The short form (2026-09-13); the install guide §1 (2026-10-02).
A record, its tries, and what came in
Every change that crosses is one record. You see it on Integration Activity: one row per try, with its state, its amount where it carries money, whose reference it is, and what went wrong. A record that is tried again gets a new row; Try No. counts them and Latest Try marks the newest.
Incoming Records is what the other system sent us, before Integration Core did anything with it — kept as received.
Each record has a direction: Inbound (coming into iVendNext from the other system) or Outbound (going from iVendNext to the other system). A refund going out and an order coming in follow the same states.
Source: the support runbook §1 (2026-09-13, re-looked-up 2026-10-02).
The states a record can be in
The list shows one plain word per state; underneath, Integration Core keeps fifteen states so the reason is never lost. Under Technical details each record also shows a three-word summary (Unprocessed, Failed, Processed) — ⛔ never reason from that summary on a money question. ⚠ It reads Failed on an Unverified record too, where nobody presses anything, and Unprocessed on a waiting record that a person must fix.
| The list reads | Stored state | What it means for the business |
|---|---|---|
| In progress | Queued · Pending · Retrying · Accepted | on its way, nothing for you to do. Accepted: the other system took it and the outcome is not final yet — if it is still not final after 4 hours, the bell says so and it is a money question for support |
| Waiting | Blocked | waiting on something this record does not have yet — often one piece of setup — or the connection is switched off. Not failed, and outside the retry limit on purpose |
| Set aside | Deferred | put aside without failing — usually expired sign-in details. Picked up by itself once the cause clears |
| Reversal not confirmed | Reversal Pending | iVendNext has reversed its side and the other system has not. On a refund, the customer's money has not left yet |
| Failed | Failed | tried and rejected. A person reads the error, fixes the cause, then retries |
| Cannot be sent · Acknowledged | Failed (a permanent loss) | the iVendNext document no longer exists, so the other system can never be told. Acknowledged once a person has said they saw it |
| Failed, with Acknowledge and no Retry | Failed (a failure no retry can fix) | the connection marked it as a failure a retry cannot fix. Fix it on the other system if it matters, then acknowledge it; it then reads Acknowledged |
| Unverified | Unverified | ⭐⭐ we cannot tell whether it reached the other system — see the next section |
| Needs a decision | Needs Decision | a person must decide what happens to this one. Never retried automatically |
| Decided · Ignored | Ignored | closed on purpose, not failed. Decided where a person closed it with Keep iVendNext Version; Ignored where the connection closed it |
| Applied | Applied | done |
| Cancelled | Cancelled | reversed on both sides |
| Superseded | Superseded | a later change replaced this one |
| Skipped | Not Applicable | nothing was owed for this document; the form shows Reason instead of Error |
| Test record | any | made by a certification run, not customer work |
Source: the support runbook §2 and §3 (2026-09-13, re-looked-up 2026-10-02); the state words read at Core rc.5.
Unverified: we cannot tell if it arrived
Unverified means we cannot tell. The send may have landed on the other system, or it may not. It is ⛔ not
failed and ⛔ not pending.
- It is never retried, and never included in a bulk retry. There is no Retry button, and there must not be: sending it again could move the same money twice.
- Only the other system can settle it — the connection's next status check, or a person on the other system. The record's Error says which, where the connector wrote one. (On Acumatica, for example, a person may need to release a document there — read Acumatica's own troubleshooting page first.)
- On the Hub it has its own tile, Cannot tell if it arrived. Opening a record says "Integration Core cannot tell whether this reached …", naming the connection.
- A burst of them right after go-live, on a system that answers accepted rather than done, usually settles on the next status check. Integration Core waits one of the connection's check intervals before alerting, for that reason.
- A record whose send was interrupted (the worker stopped mid-send) is moved to Unverified once its lock is stale: 30 minutes by default, checked every 5 minutes, so up to about 35 minutes.
⛔ If one is still there tomorrow, raise a ticket. Do not look for a way to force it.
Source: the support runbook §2 (Unverified, Pending) and §8 item 2 (2026-09-13); the setup guide, Step 7 item 2 (2026-09-27).
Why some records refuse a retry
Nine states refuse a retry, each with its own reason: Pending · Accepted · Reversal Pending · Unverified · Needs Decision · Applied · Cancelled · Superseded · Not Applicable. Some because Integration Core cannot tell whether the first send arrived; others because the change already landed and sending it again would put back an old version or repeat something done. There is no override, for anyone — not a System Manager either.
The record's own screen says which reason applies, in the same words the Retry selected confirmation uses.
A record in any other state shows Retry to someone who may edit it, while its connection is switched on and its connector offers a retry: Failed, Set aside, Waiting, In progress (queued or retrying), Decided and Ignored. A failure the connection marked as one no retry can fix, a lost document (Cannot be sent) and a test record show none. On a record that is not Failed the connector may decline; a declined record is reported apart ("… were not sent again", in orange). That is correct behaviour.
⚠ Two places a Retry button is offered and should not be pressed:
- Held behind an unknown attempt (a Waiting record): an earlier attempt at the same record may already have reached the other system. ⛔ Leave it until that settles.
- Decided: retrying a record someone closed with Keep iVendNext Version can put it back to waiting while it still counts as decided — then no alert rings and Money records waiting does not count it. If you press it, follow the record on Integration Activity yourself until it finishes.
Source: the support runbook §2, Which states refuse a retry (2026-09-13); the known issues §2, IC-MONEY-SHOWN-B1
(2026-10-02); the support runbook §3, the single-row Retry button is drawn on all six runnable states (corrected
2026-10-07); the Retry and Acknowledge buttons read at Core rc.5 and again at rc.8.
Sync positions: how far each sync has got
For each connection, record type and direction, Integration Core keeps a sync position — how far the connection has read the other system's changes, or sent ours. You see them on Sync Positions (under Advanced). They are read-only.
⛔ A position moved by hand skips every change between the two positions, silently. It is the most destructive edit these screens could allow, which is why none is allowed.
Source: the support runbook §1 and §4 (2026-09-13).
Record links: which record is which
A record link joins a record in the other system (by its ID in Connected System) to an iVendNext record. You see them on Record Links (under Advanced). The connection makes most of them as it syncs.
- Link manually joins two records by hand, for a record waiting because no link exists yet. ⛔ A link a person made is never changed by syncing — if it is wrong it stays wrong until somebody presses Make inactive on it.
- Both buttons need permission to change the iVendNext record as well as the connection.
- An iVendNext record another system is linked to cannot be deleted; disable it instead.
Source: the support runbook §1, §4 and §10 (2026-09-13); What Integration Core gives you today, The bounds.
Waiting rows and why they wait
A Waiting record (stored as Blocked) is waiting on something it does not have yet. Its form says Waiting on: and the reason. The Hub splits them into three links because each needs something different:
- Kept while switched off — changes that arrived while their connection was off. Switching it on picks them up, about 500 an hour after the first batch.
- Held behind an unknown attempt — ⭐⭐ held back because an earlier attempt at the same record may already have reached the other system. ⛔ Do not force it; only the other system can settle the earlier one.
- Waiting on a setup change — waiting on something missing, often one piece of setup. One missing piece often holds many records at once: fix the one thing and they all move. Where the connector named the field, the record offers Open the fix (or Ask a … if you may not change it).
⚠ The three-word summary shows a waiting record as Unprocessed, which reads as nobody acts — but a setup wait is work for a person. Treat a full Waiting on a setup change list as work.
Source: the support runbook §2 and §8 item 1 (2026-09-13); the setup guide, Step 1 and Step 7 (2026-09-27).
Differences: where the two systems disagree
A Difference records that iVendNext and the other system disagree about one record. Its kind says how: Field Mismatch · Missing Ours (the iVendNext record was deleted while its link is active) · Missing Theirs · Multiple Matches · Renamed (renamed in iVendNext) · Link Moved · Manual Mapping Skipped · Cancelled in iVendNext (a document the connection had sent was cancelled in iVendNext).
⛔ Integration Core records a difference; it changes nothing in either system. A person deals with it on the right side, then presses Mark resolved and says what they did. An open difference is reported again by every reconciliation pass while it stays open.
Source: the support runbook §3b (2026-09-13, rc.4 words).
The switch: off keeps the work
Switch off stops sending and applying for a connection. Changes that arrive while it is off are still recorded and marked as waiting — nothing is dropped to stop it. Switch on re-queues the kept changes, oldest first: one batch at once, then 500 an hour.
Who last changed the switch, and when, is shown on the connection. After an upgrade it may read Administrator — that is the system signing its own decision, not a person.
There is no disconnect action: switching off is the supported way to stop an integration. ⛔ Uninstalling Integration Core deletes its whole history and every record link — and after a reinstall nothing tells a connection what it already sent, so its first sync can post the same sale or order a second time. On rc.5 Core itself does not refuse its uninstall once the connectors are gone (rc.6 refuses it while any record link is active). Treat it as permanent; never uninstall to "fix" a site.
Source: What Integration Core gives you today, A switch that keeps the work; the setup guide, Step 5 and Removing a
connection (2026-09-27); the support runbook §7 and §10b item 1b; the known issues §5, IC-DP10-B21 (2026-10-02).
The Hub, the bell, the email and the daily summary
The Integrations Hub answers one question: is anything waiting for a person? Six count tiles — Needs a decision, Failed, Cannot tell if it arrived, Money records waiting, Differences, Connections with a problem — and cards of links. A state link opens a short report of exactly the rows that state counts.
Connection Health (a report, on the Your connections card) is every connection in one line: its state in words, since when, when it last looked for changes, and its counts. It is the place to start each day.
The bell at the top of the screen carries alerts when something is genuinely stuck — a reversal owed for four hours, a connection that has stopped looking, refused sign-in details, an unreachable system. Each reads the sentence first and a short code ([ic:…]) last. ⚠ One alert can stand for many records — alerts are grouped per connection, per kind, per hour — so always count the rows, not the alerts. A connection's alert goes to the Integration Managers who may see that connection (a User Permission on the Connection can limit a Manager to some connections); if none may, to the System Managers — never to nobody. A line that names the connection uses its display name, never the platform alone.
Alert email (a copy of the shipped Notification that a System Manager switches on) and a daily summary (Email me a daily summary in the Connections list's ⋯ menu) are both opt-in. ⚠ Every alert and email is a scheduled job: if the site's scheduled jobs stop, nothing rings and nothing is emailed.
⛔ A connection that has never run raises no alert at all. It shows Not reported yet and somebody has to look.
Source: the setup guide, Step 1, Step 7 and Getting alerts by email (2026-09-27); the support runbook §6 (2026-09-13, re-looked-up 2026-10-02).
What is kept, and for how long
The full message each integration receives is stored as received, and cleared 30 days after arrival by a daily job, together with its delivery headers. The error text and the waiting reason are cleared 30 days after a record finishes.
⛔ The 30-day rule does not cover everything. A message whose record has not settled is kept, because it is the only copy. The request and reply payloads and the disputed content have no retention. An open difference keeps its two values until somebody resolves it. Without the scheduled jobs, nothing is cleared.
A System Manager can erase one person's data on Integration Activity, Incoming Records and Differences (Erase personal data). ⛔ It cannot be undone: an incoming record not yet applied can no longer be applied. Erase personal data even if unfinished is only for a record that will never finish — on a live one the connection loses what it decides from. It also reaches each connection's own copies of those records, where the connector declares how (from build 2.0.0.166); if a connection cannot erase its copies, the record gets a comment naming that connection and the Error Log a line — Integration Core's own erase still stands. The erase does not reach alerts already in the bell's log, emails, or any copy someone exported or printed; the support runbook §9 is the full procedure.
Source: the support runbook §9 (2026-09-13); the install guide §7 (2026-10-02); the setup guide, Getting alerts by email (2026-09-27).