Skip to content
VEYQON
Platform · Build & connect/INT

Everything else you run, connected.

Bank feeds, e-invoicing, carriers, payment providers, and the tools your teams already use. A connector is configuration rather than a six-month project — and where one does not exist, the same REST surface the interface uses is open to you.

Categories named below·Two-way where it makes sense·Failures are records

What it does · 17 capabilities/01

How a connector behaves.

The categories are on this page further down. This section is about the properties every connector shares, which is what decides whether an integration is maintainable a year later.

01

Credentials and access

How a connection is held, and how narrowly.

  • Scoped per connector

    Credentials are stored encrypted against the connector, not in a shared secrets file, and are never readable back through the interface or the API.

  • OAuth where offered

    Token refresh handled, with expiry surfaced before it breaks rather than as a silent stop at the weekend.

  • Least privilege by default

    A connector asks for the narrowest scope that does the job. Where a provider only offers a broad scope, the connector page says so.

  • Rotation without downtime

    Credentials can be replaced while the connector runs, so a rotation policy does not require an outage.

02

Mapping

Matching their fields to your ledger, once.

  • Versioned mappings

    A mapping is a record with a history, so a change that broke something last Tuesday can be found and reverted.

  • Reviewable before it applies

    A mapping change is reviewed like any other document, rather than edited live in a settings page.

  • Unmapped values surface

    A value that does not match anything becomes an exception rather than defaulting to something plausible and wrong.

  • Per-company mappings

    The same provider mapped differently for two entities in a group, which is normally where a single-mapping design falls over.

03

Movement

How data actually travels, and how often.

  • Event-driven where supported

    The provider pushes and we act. Polling is a fallback for providers that do not offer webhooks, not the default.

  • Two-way where it makes sense

    Some connectors write back — a shipment reference, a payment status. Some deliberately do not, and the page says which.

  • Idempotent by design

    A replayed event does not double-post. This is what makes retry safe rather than dangerous.

  • Backfill

    Pull a historical window on connection, so the first day is not a cliff between old data and new.

04

Failure

The part that decides whether you trust it.

  • Failures are records

    A failed sync is a document with an error, a payload, and a retry — not a silent gap in the ledger discovered at month end.

  • Retry with backoff

    Transient failures retry automatically; persistent ones stop retrying and escalate rather than hammering a provider.

  • Dry run

    Pull real data and see exactly what would post, before anything does. Available on every connector, not just at setup.

  • Circuit breaking

    A provider returning errors is backed off rather than retried into a rate limit, with the state visible.

  • Reconciliation report

    What they say against what we hold, per connector, so drift is found by a report rather than by a customer.

Connecting one/02

Configuration, not integration work.

The third step is the one to insist on. Any connector that cannot show you what it would post before it posts is not finished.

  1. 01

    Authorise

    Connect the account. Credentials are stored encrypted and scoped to the connector.

  2. 02

    Map

    Match their fields to your ledger once. The mapping is versioned and reviewable.

  3. 03

    Dry run

    Pull real data and see what would post, before anything actually does.

  4. 04

    Monitor

    Failures surface as records with a retry, not as a silent gap in the ledger.

The catalogue/03

What connects, by category.

Named categories with representative systems rather than a logo wall. Where your provider is not listed, the REST and webhook surface is the same one the connectors are built on — so the answer is a configuration exercise, not a rebuild.

01

Banking and cash

Feeds in, payments out, and the reconciliation between them.

  • Open Banking feeds

    Account information and transaction feeds under UK and EU Open Banking, refreshed on the provider's cadence.

  • Statement formats

    CAMT.053, BAI2, OFX, MT940, and delimited exports, with a saved column mapping per bank.

  • Payment initiation

    Payment files and initiation APIs, with the resulting payment entry matched back to the invoices it clears.

  • Card and expense providers

    Card transaction feeds landing as expense claims or purchase invoices with receipts attached.

02

E-invoicing and tax

Statutory submission, validated before it leaves.

  • Peppol

    Access-point submission and receipt of BIS Billing documents, with validation before anything is sent.

  • National mandates

    Country-specific clearance and reporting regimes, installed by region rather than carried everywhere.

  • Making Tax Digital

    UK VAT submission from the same ledger the return is computed on.

  • Validation first

    A document that would be rejected is stopped here with the reason, rather than after a round trip.

03

Carriers and logistics

Rates, labels, and proof, back onto the delivery note.

  • Parcel carriers

    Rate shopping, label generation, and tracking against the shipment record.

  • Freight and pallet networks

    Booking and consignment references held on the delivery note rather than in a portal.

  • Tracking and proof of delivery

    Status and POD written back to the delivery, so a customer question is answered from your own records.

  • Customs documentation

    Commodity codes and country of origin from the item master feeding export paperwork.

04

Payments and collections

Money in and out, matched to what it settles.

  • Card and wallet gateways

    Gateway accounts mapped to bank accounts so settlements land in the right ledger rather than one lump.

  • Direct debit

    Mandate handling, collection runs, and failure reasons returned onto the invoice.

  • Payouts

    Supplier and partner payouts, with the remittance matched to the documents it clears.

  • Settlement reconciliation

    Gross, fees, and net separated so the fee is an expense rather than an unexplained shortfall.

05

Identity and workplace

Where your joiners and leavers are already handled.

  • SSO

    SAML 2.0 and OpenID Connect against your existing identity provider, including enforced MFA.

  • SCIM provisioning

    Joiners, movers, and leavers applied automatically, so access review is a shorter conversation.

  • Directory groups to roles

    Group membership mapped to platform roles, with the mapping versioned like any other.

  • Mail and calendar

    Inbound mail creating documents and tickets, and calendar events for appointments and site visits.

06

Everything else

The systems that have no connector yet.

  • REST and webhooks

    The same surface the interface uses, so anything a person can do a system can do.

  • Typed SDKs

    TypeScript and Python clients generated from the same definition the API serves.

  • iPaaS

    Where you already run an integration platform, the API and events are ordinary endpoints to it.

  • Flat file and SFTP

    Scheduled import and export with a saved mapping, for the trading partners who will never offer an API.

The spec/04

The specification.

What to check on any connector before you depend on it.

Transport
Webhook-first; polling only where a provider offers no push
Credentials
Encrypted per connector, never readable back, rotatable live
Mappings
Versioned records, reviewable, per company
Idempotency
Replayed events never double-post
Failure
A record with payload, error, and retry — never silent
Backoff
Exponential retry with circuit breaking on persistent errors
Verification
Dry run available at any time, not only at setup
Drift
Per-connector reconciliation report
Where it stops/05

What a connector will not do for you.

The honest limits of the category, stated so that an integration plan is built on them rather than around them.

It cannot beat the provider's API
If a bank refreshes twice a day, the feed is twice a day. A connector cannot make somebody else's system real-time, and we will tell you the cadence rather than imply live.
It will not reconcile bad identifiers
Two-way sync needs a stable key on both sides. Where the other system has none, that is a data project first and an integration second.
Not every connector writes back
Some are deliberately read-only, because writing into a system of record you do not control is how two systems start disagreeing.
Count is not coverage
A large connector count means little if yours is not among them. Ask about your specific providers; we would rather scope a build than claim a number.

Next step

Bring one process. We will run it live.