We connect 1C and external APIs fast — and make the exchanges manageable

Integrations and 1C work

Integrations usually live in people's heads and in code nobody dares to touch. We put that in order: versioned message contracts, one bus with delivery guarantees, and a live as-is map of the exchanges. On top of it — access for assistants and agents over the open MCP protocol, so routine 1C and external-API work happens fast and by the rules. We also put 1C configurations under version control so changes stop being irreversible.

Discuss your case What is included

01Who it is for

Companies with several 1C databases and integrations nobody dares to touch
Teams that need to replace a heavy system without stopping the business
IT teams that need to give assistants safe access to accounting systems

02What it replaces

Direct database links from a neighbouring service
Scheduled nightly file exports
Integrations only one person understands

03What is included

What is included

Assistant access to systems

1C, CRM and external APIs over an open protocol

in production

The layer through which assistants and agents get safe access to accounting systems, CRM and external APIs over the open MCP protocol: a set of permitted operations rather than raw database access.

The job

Give assistants hands — while keeping every action limited, named and logged.

What hurt

Automation stalls because the assistant has no access to the systems
Direct database access is dangerous and never gets approved

What you get

The assistant performs operations itself, within a permitted set
Every action is named and logged, so an incident can be investigated
A new integration is connected in days, not in a quarter

What your client gets

Routine requests are handled without waiting for a free specialist

last change: 04 Sep 2026

Exchange bus

One envelope, delivery guarantees, tracing

in production

The central exchange bus between systems: one message envelope, versioned contracts, idempotency, retries with backoff, a dead-letter queue and end-to-end tracing. No new infrastructure — it runs on the database you already have.

The job

Make system-to-system exchanges predictable: no lost messages, no duplicates and always visible in flight.

What hurt

Every integration is written differently, each with its own failure modes
A lost message is discovered by a complaint, not by monitoring
A system cannot be replaced because dozens of direct links hang off it

What you get

Delivery is guaranteed and a retry does not create a duplicate
A message's whole path is visible; investigation takes minutes
A system can be replaced whole without touching its counterparties

What your client gets

Data does not drift between systems and an order is not lost at a seam

last change: 04 Sep 2026

1C gateway

One door instead of a dozen integrations

in production

One access point to the accounting core: external services reach 1C through a gateway by contract instead of connecting to the database directly.

last change: 16 Jul 2026

Exchange contracts

Message definitions kept apart from code

in production

Versioned definitions of the messages systems exchange. A contract describes the message, not the service code, so a system can be replaced without rewriting everyone who talks to it.

last change: 17 Jul 2026

1C under version control

Configurations as source code

in production

Accounting system configurations are exported into repositories: every change has an author, a history and a way back. A modification stops being an irreversible operation.

The job

Make 1C changes reversible and reviewable, the way ordinary software development works.

last change: 03 Sep 2026

04How it works for you

How it works for you

Map the exchanges

We assemble from the data how systems actually talk, not how it was designed.

Describe the contracts

A message gets a versioned definition, kept apart from any service code.

Install the bus

One envelope, idempotency, retries with backoff, a dead-letter queue and tracing.

Move the load

The new service runs beside the old one and takes over traffic piece by piece.

05Comparison

Three ways to solve this

We are not the only option, and we show plainly where we lose.

	Build it yourself	Off-the-shelf vendor	BIOCARD Tech
Time to first result	Quarters: hiring, learning the domain, architecture from scratch	Weeks to install — then months bending processes to fit the box	A demo immediately, a pilot in weeks: the product already exists
Domain context	You will have to teach the team what a batch and a temperature mode are	A generic product with no notion of a shipment or a cold chain	We work in it daily — the context is included
Who carries the risk	You do: for the timeline and for the solution turning out wrong	You do: changes outside the vendor roadmap usually never happen	We do: the product runs in our own company and we use it ourselves
Changes for you	Anything is possible — if the team stays and is not pulled elsewhere	On the vendor's roadmap and priorities	Days rather than quarters: our own delivery pipeline
Where we lose	Full control over the code and priorities stays with you	A large partner ecosystem, training and certification	We are a small team and we do not take every job

06Cost

Price on request

There is no price list, and that is not a trick: almost every product needs configuration for your processes and integrations, so the same system costs differently at two companies. We quote after the demo, when the scope is visible — not before it.

What you get

A working product rather than from-scratch development. The core already exists and runs in our own company, so you pay for the rollout and the fit-out, not for inventing the solution.

What the quote is made of

The amount of fit-out for your processes, the number and complexity of integrations, and the requirements around data and timing. All of it becomes visible after a demo on your own data.

When we name a figure

After the demo and a short review of your case. The quote is fixed — not time-and-materials.

Where the work stops

We do not rewrite your 1C wholesale by default: first the exchanges become manageable, and only then do we discuss what to replace — or whether to replace anything at all.

07FAQ

Questions about this solution

Do we need downtime to switch over?

No. The new service computes in parallel with the old one for a while, discrepancies are visible, and the cutover happens domain by domain rather than all at once.

What is MCP access and why?

It is an open protocol through which an assistant receives a list of permitted operations rather than the database. Every action is named and logged, so it can be approved and audited.

Can 1C configurations really live in Git?

Yes — that is how we keep ours: every change has an author, a history and a way back.

See it on your data

Forty minutes, a working product, no slides. Then a pilot in your environment.

Discuss your case +7 499 346 3588

All solutions →