OpenIntegrations: one API library for 1C, OneScript, and the command line

Two delivery forms for the same methods

OpenIntegrations is described as a set of tools for working with external APIs, and the interesting sentence is about the two forms it takes.

The first is a library, an extension, for 1C:Enterprise or for OneScript. The second is a cross-platform console application for Windows and Linux. The same set of operations is available through both, and the console application is the one that makes the library usable from a shell script or a scheduled job.

That second form is what makes this project unusual in the 1C ecosystem. The console tool is invoked with a service name, a method name, and arguments, which means an operation that lives in the accounting platform can be run from a deployment pipeline without a 1C runtime anywhere near it. The description also mentions MCP, which puts the same operations behind a protocol that an assistant can call.

The scope is more than thirty services and technologies, and the tasks are the applied ones rather than the transport ones: sending a message, creating a document, running a query. That distinction matters, because a client library that exposes raw HTTP for every service is not much more than a wrapper around a request, while a library that knows how to send a picture to a chat and how to write a row to a table is doing the work for you.

The project is MIT licensed, the site is openintegrations.dev, and the last push was on 2026-10-10. The releases are versioned by hand with a date attached, so the history reads as 2.1.0 in May 2026, 2.2.0 in June, and 2.3.0 in July, which is a monthly cadence.

The readme is in Russian and an English version is kept beside it, which is worth knowing before you start reading the documentation.

Independent modules over shared components

The architecture paragraph in the readme is the part that explains why the project can cover thirty services without becoming thirty programs.

The code is organised as a set of independent modules, each responsible for one specific service. What is common, the readme says, such as the work with HTTP or JSON, is factored out into reusable components.

That is a plain and correct design, and it buys two things. The first is speed of adoption: a ready-made function is a call, not an integration project. The second is extensibility, because a new method is added on top of the existing components rather than by writing a new HTTP layer, and the readme makes that point explicitly.

The two hosts make the same point from the other side. The library form and the console form are two front ends over one body of methods, so the operational logic is written once. That is the difference between a project that maintains integrations and a project that maintains two products.

The open source position is stated in the same paragraph. The source is open, which gives full control over the implementation, and it is the reason the community can take part in the development. The repository is set up accordingly, with a contributing guide, a code of conduct, a changelog, an agent instruction file, a notice file, and a separate third party licence list, which is the set of files a project needs when it is built from many contributors and ships code it did not write.

There is also a continuous integration directory and a data file with an encrypted extension, which is the kind of thing a project keeps when it publishes signed or encrypted configuration alongside its code.

The catalogue, in four families

The service list is the fastest way to see what the library is for, and it falls into a few clear families.

The messengers and communication services are the largest group: Telegram, VK, the VK Teams variant, Viber, GreenMax, and GreenAPI, with Bitrix24 alongside them as the platform most 1C installations already live inside, and CDEK for shipping logistics. The Russian and international mix is deliberate, since the project comes from that market and the messenger APIs there are the ones businesses actually automate.

The cloud and storage group covers Google Calendar, Google Drive, and Google Sheets, Yandex Disk, Dropbox, Notion, Airtable, S3, and Slack, with a Notion entry in the repository topics alongside the database ones.

The databases are the widest single group: PostgreSQL, MySQL, MSSQL, SQLite, ClickHouse, and MongoDB, plus a couple of query oriented protocols in the topics. That is the group where the library earns its keep in an accounting context, because a business application is full of reads and writes against its own database and the value of a shared query component is that the same helper works for every engine.

The protocol group is the one that makes the library more than a set of API wrappers. There are TCP, HTTP, WebSocket, GRPC, SSH, SFTP, FTP, RCON, ZeroMQ, and Lua, and the topics also carry a Google Cloud entry, an Airtable entry, and a Twitter entry. These are the primitives you reach for when the integration you need is with a device or an internal service rather than with a product.

And the model oriented entries sit with the cloud group: OpenAI and Ollama, so the same library that sends a message to a chat can also call a language model.

Data formats, and archives

The second grid in the readme is a shorter one, and it covers the data formats the library can read and write alongside the services it can talk to.

There is RSS, which is the format the library can consume as well as produce, and Janx, and MessagePack, which is the compact binary serialisation format that appears in a lot of internal service APIs.

Then there are the archive formats: 7z, RAR, and Tar. That trio is a deliberate choice, because those are the formats a business user actually receives, and a library that can unpack what a colleague sent is more useful in that context than one that can only read a format the sender happened to choose.

Both grids point at the same documentation structure, with a page per entry under the instructions section of the site, so the catalogue is not a list of logos but an index into a set of guides.

Taken together, the two grids describe a library whose scope is the whole path a piece of data travels, not only the endpoints. A file arrives as an archive, is unpacked, is parsed as RSS or MessagePack, is written into a database, and is announced in a chat, and each of those steps is a call into a module the library already ships.

The example, and what the two APIs look like

The readme shows one operation, sending a picture to a Telegram chat, in both of the delivery forms, and the pairing is the clearest statement of the design.

In the 1C or OneScript form the call is a single function on a namespaced object, with the token, the chat identifier, the text, and the picture as arguments, and the readme shows it like this.

    
    Токен    = "6129457865:AAFyzNYOAFbu...";
    IDЧата   = "461699897";
    Текст    = "Крутая картинка";
    Картинка = "C:/picture.jpg";  // URL, путь на диске или Двоичные данные

The picture argument accepts a URL, a path on disk, or binary data, which is the detail that makes the function usable from the platform, where a file on disk and a blob in memory are different things.

In the console form the same operation is a service name, a method name, and the arguments, run from a shell. The readme presents it as a bash example with a line continuation, and the tool itself is a short command.

So the operation is the same in both, and what changes is the calling convention. From 1C it is a function call inside a transaction or a scheduled job, and from a shell it is a command in a script, and the arguments cross the boundary in the order you would expect.

The project is a member of the OneScript ecosystem, it has a Telegram channel, and the repository carries a badge pointing at the ecosystem's own site, which is how a Russian 1C project signals which community it belongs to.

For an evaluator, the practical question is whether the thirty plus services are actually implemented, and the readme points at a catalogue page for exactly that check, since the grid of logos in the readme and the catalogue of implemented methods are two different things.

Governance, licensing, and the documentation site

The repository is set up like a project with a process rather than a set of scripts, and the files are the evidence.

There is a contributing guide and a code of conduct, a changelog, an agent instruction file for automated contributions, and a notice file with a separate directory of third party licences. The licence is MIT, and the third party list exists because a library that wraps thirty different services' protocols will contain code that is not the author's own.

There is also a git attributes file and a continuous integration directory, and a documentation directory in the repository alongside the media directory that holds the images used in the readme and the badges, which is the arrangement of a project whose documentation is written alongside the code rather than somewhere else.

The main site is openintegrations.dev, and the readme points into a documentation section with an instructions page per service, which is where the actual usage is. There is a grid of images for each service, and the readme's own images are referenced from a media directory in the repository, so the site and the repository are two views of the same material.

The project also links to a donation platform, and the readme carries badges for the ecosystem, the messenger channel, and the funding link, so the three communities it serves are named in the header.

What that amounts to is a library with a real process around it, which matters for an extension that goes into a business accounting system, where a change in behaviour can have consequences that a test suite does not cover.

Editorial conclusion

OpenIntegrations fits a team that runs a 1C:Enterprise installation and needs to reach out to messengers, cloud storage, databases, and internal protocols without writing a client for each, and a team that wants the same operations available from a shell for automation. It does not fit a developer who wants a modern typed client for one service, because the value here is the breadth and the shared plumbing rather than the depth in any one integration. Verify first which of the thirty plus services the library actually implements today rather than the ones listed in the catalogue, that the console application runs on the operating system you deploy to, since it ships for both Windows and Linux, and that the licence terms cover the third party components, because the repository tracks those separately with a notices file and a third party licence list.

Frequently asked questions

Official sources

1. Bayselonarrend/OpenIntegrations on GitHub
2. License: MIT
3. Project website
4. README
5. Releases