1C API: REST, HTTP Services and OData
We make 1C accessible to websites, mobile apps, bots and partners. A REST API on HTTP services inside 1C or the standard OData interface, JSON exchange, with authorization, logging and documentation.
- A 1C REST API in JSON built around your scenarios, not raw tables
- Standard OData for fast catalog and stock reads
- Authorization, access restrictions and a request log
- Documentation for the external system's developers
A 1C API built on HTTP services starts at 350,000 tenge and takes two to three weeks. A version with caching, a queue and load limits takes from four weeks.
Why 1C needs an API
When other systems need to reach 1C data, and do it reliably.
1C holds what matters most: products, prices, stock, customers, orders, receivables. Sooner or later that data is needed outside. The website needs the catalog, a sales rep app needs stock and the client's prices, a Telegram bot needs the order status, a partner needs a price list in their own format.
The typical picture without an API: once a day a manager exports an Excel file with stock and emails it to partners, the website updates from a nightly file, and the mobile app shows yesterday's data. Every channel lives with its own delay.
Without an API, exchange relies on file exports, manual reports or direct database access that breaks with every update. A 1C API makes exchange predictable: the external system sends a request and gets a response in clear JSON, while access rules and validation stay inside 1C.
Another argument for an API is speed of change. When a new app or partner appears, it connects to the API that already works instead of getting yet another separate exchange. A year later the company does not have five forgotten exports but one clear entry point into 1C with a log and access rights.
A good API lives for years. The configuration gets updated and internal tables change, but the external contract stays the same, so the app does not need any rework.
Three ways to open up 1C data
The choice depends on the task: reading, writing or both.
| Approach | When it fits | Timeline and price |
|---|---|---|
| Standard OData interface | fast reading of catalog, stock and reference data | 2-3 weeks, from 350,000 ₸ |
| HTTP service (REST API in JSON) | two-way exchange, custom logic, apps | 2-3 weeks, from 350,000 ₸ |
| HTTP service with cache and queue | high load, many clients, instant events | from 4 weeks |
| SOAP web service | a partner or government system requires SOAP | by estimate |
Sometimes the reverse path is needed too: 1C itself notifies an external system about an event, for example an order shipped or a payment received. In that case 1C calls the external system's address right after the document is posted, and the app learns about the event within seconds instead of at the next poll.
For most tasks we recommend an HTTP service: the external system does not need to know the internal structure of the configuration, and validation logic stays in 1C. OData is good where a fast start for reading is needed. A comparison of both approaches with examples is in OData or HTTP services (in Russian).
REST API on 1C HTTP services
The main approach for apps, websites and bots.
An HTTP service is a 1C configuration object that accepts ordinary HTTP requests and responds in JSON. We design it around your scenarios, not the database structure. For example, instead of returning the entire stock table, the app asks for "stock of products in this category at the Astana warehouse" and gets a short answer.
A typical set of 1C REST API methods for a trading company:
- catalog with attributes and changes since the last request;
- prices by the client's price type and stock by warehouse;
- order creation with price, stock and credit limit checks;
- order, shipment and payment status;
- customer card: balance owed, bonuses, purchase history.
For catalogs of tens of thousands of items we add pagination and change tracking: the app does not receive the whole catalog on every request, only what changed since last time. That cuts traffic and server load by an order of magnitude.
The HTTP service goes into a configuration extension, so the standard configuration stays on vendor support. It is published through a web server you already have or one we set up.
The standard OData interface in 1C
A built-in platform mechanism for fast data reading.
The standard OData interface has been in 1C for a long time and is supported by all current configurations on the 8.3 platform. For many reading tasks it is the fastest way to get a 1C REST API without a single line of code inside the database.
The 1C:Enterprise 8.3 platform can automatically publish configuration objects over the OData protocol. No code in 1C is needed: you select the objects and publish the database on a web server. The external system can immediately read catalogs, documents and registers.
It is important to understand OData's limits upfront. The external system works with internal 1C object names, so its queries may break when the configuration changes. Writing through OData bypasses part of the business logic, so we do not use it to create documents. And at large volumes OData loads the server more than a purpose-built method.
OData queries are written in a standard form: filters, field selection, sorting, pagination. Many off-the-shelf analytics tools and integration platforms can work with OData directly, which is another reason to use it for reading.
A good setup in practice: OData for reading catalog and stock at the start, an HTTP service for writing orders and for everything that grows.
Security and load
An API opens access to your accounting. So it has to be protected.
- A dedicated user with minimal rights. The API sees only what it needs and cannot, for example, change prices.
- Token or login authorization. Each external system gets its own access that can be revoked separately.
- HTTPS. Data between 1C and the external system travels encrypted.
- Request log. Who asked what, when, and with which error. This is the first place we look in any incident.
- Rate limiting. An external system cannot flood 1C with requests and slow down the accounting team.
- Cache for frequent requests. Catalog and stock are served from a cache instead of being recalculated on every call.
For requests that change data, such as creating an order, we add protection against repeats. If the connection drops and the app sends the order twice, 1C creates it only once. Without this, duplicate orders appear every time a sales rep has a weak connection.
For mobile apps with thousands of users we add an intermediate layer: the app talks to it, and it syncs with 1C every few minutes. That way the load on 1C does not depend on the number of users.
How we build a 1C API
From scenarios to methods, from methods to documentation.
- Scenarios. What the external system does: shows the catalog, creates an order, checks the balance owed. The scenarios give us the list of methods.
- Contract. JSON request and response formats, error codes. Agreed with the external system's developers before any code.
- Development. An HTTP service in an extension on a copy of the database, with validation and logging.
- Test environment. The external system connects to the copy and checks every scenario on real data.
- Publishing. Web server, HTTPS, permissions and limits.
- Documentation. Method descriptions with request and response examples, so any developer can connect without us.
Versioning is built in from day one. When a response format has to change, a new version of the method appears while the old one keeps working until every external system has moved over. That way an API update never stops working apps.
The whole path for an API covering one task usually takes 2-3 weeks, one of which goes to testing together with the external system's developers.
If we also build the external system, such as a website or mobile app, the contract is designed once for both sides.
Tasks that need an API
The most common scenarios for companies in Kazakhstan.
Mobile app for sales reps. Catalog, client prices, stock, order creation with a credit check. The app itself is built by our team at Applications.kz, and we build the API on the 1C side.
Website and B2B customer portal. The client sees their prices, stock, order history, reconciliation statements and balance owed. More on the 1C website integration page.
Telegram bot and notifications. The bot asks 1C for an order status or stock level, and 1C sends event notifications on its own.
Warehouse and handheld scanners. Data collection terminals and warehouse apps receive picking tasks and send results to 1C with no files or manual copying. More on the warehouse automation page (in Russian).
Partners and suppliers. A dealer receives the price list and stock automatically instead of waiting for a file by email.
Analytics and dashboards. 1C data flows into a BI system or your own dashboard. See the 1C reports page.
How much a 1C API costs
The price depends on the number of methods, the load and the state of the database.
| Work | Timeline | Price |
|---|---|---|
| OData publishing for reading | 2-3 weeks | from 350,000 ₸ |
| HTTP service for one task | 2-3 weeks | from 350,000 ₸ |
| REST API with cache, rate limits and log | from 4 weeks | by estimate |
| Exchange with a queue and events | 6-10 weeks | 1,500,000-3,000,000 ₸ |
| API support | monthly | from 80,000 ₸/month |
The work splits neatly into stages: first the read methods the external system can already work with, then order writing and events. You accept each stage on the test environment before paying for the next.
Documentation and the test environment are included in the price. It costs more if the database has many old undocumented edits to the standard configuration, since they take time to untangle. It costs less if we also build the external system and the contract does not have to be agreed with a third party.
Common mistakes when opening up 1C data
What we fix after other people's integrations.
Most of these mistakes come not from carelessness but from haste: the API was needed yesterday, so it is built to work today. Six months later the savings turn into stopped sales.
- Direct SQL database access. The external system reads tables directly. It works until the first update, then breaks without warning.
- An API user with full rights. A bug in the app can change or delete accounting data.
- Writing documents through OData. The document is created bypassing validation, and accounting later has to figure out where it came from.
- No log. When something fails, there is no way to tell whether the website sent the order and what 1C replied.
- No documentation. The developer who built the API has left, and nobody knows which methods exist or how to call them.
Why us
We see the exchange from both sides and leave you the documentation.
We program 1C and build websites, apps and bots. That is why we design an API to be convenient to use, not just to work. The contract, documentation, test environment and log are part of the job by default.
We work remotely with all of Kazakhstan. We connect to a copy of the database through access you control, and publish to the live server at an agreed time so staff are not disturbed.
The code lives in an extension, so the standard configuration updates normally. Source code and documentation are handed over to you. If you have your own 1C developer or an external developer, they can continue without us. If logic changes are needed inside 1C itself, they are made by the same 1C developer who writes the API.
FAQ about the 1C API
REST API, OData and security.
Does 1C have a ready-made REST API?
The platform can publish the standard OData interface, which is a ready-made REST interface for reading. For writing and custom logic we build an HTTP service that responds in JSON.
How much does 1C API development cost?
From 350,000 ₸ for an HTTP service covering one task or for OData publishing, 2-3 weeks. An API with cache, rate limits and logging takes from 4 weeks.
Which is better: OData or an HTTP service?
OData is faster to launch for reading. An HTTP service is more stable across updates and safer for writing, because validation stays in 1C.
Will the API slow down 1C?
No, if request frequency is limited and frequent responses are cached. For apps with thousands of users we add an intermediate layer.
Does a 1C API need a web server?
Yes, HTTP services and OData are published through an Apache or IIS web server. We will set it up with HTTPS if you do not have one yet.
Will the API break after a 1C update?
An HTTP service in an extension survives updates to the standard configuration. The contract for the external system stays the same even if something changes inside 1C.
Does the API work with a file-mode 1C database?
Technically yes, but for constant load we recommend the client-server mode. We can help you choose a server.
Do you provide API documentation?
Yes, always: method descriptions, request and response examples, error codes. Plus a test environment on a copy of the database.
More 1C services
Related tasks that usually go together.
1C integration
Exchange with your website, CRM, bank and marketplaces.
1C Kaspi integration
Prices and stock to Kaspi, orders back to 1C.
1C developer
Custom 1C development priced per task.
1C reports and dashboards
Analytics on 1C data inside and outside 1C.
Server for 1C
Client-server 1C on a server in Kazakhstan (in Russian).
Send a request
Describe the task: we reply within one business day and quote before any work starts.