# 1C and website data exchange: HTTP service or OData, auth, errors

> A website can talk to 1C in two ways: the standard OData interface for simple reading and writing of objects, or your own HTTP service for custom logic. Never expose the database to the internet directly: use a proxy with restrictions, a separate user with a narrow role and an exchange with retries and duplicate protection.

Date: 2026-10-30 · Source: https://oneswitch.ru/en/blog/obmen-1s-s-sajtom-http-servis-odata/

A website and 1C usually exchange data in two scenarios: the site pulls the catalog, prices and stock from 1C, and 1C pulls orders and leads from the site. Here are two approaches and the rules that keep the exchange from becoming a source of failures.

## Two approaches: OData and an HTTP service

| | **OData (standard interface)** | **HTTP service** |
|---|---|---|
| What it is | Built-in REST-like access to configuration objects | Your own methods with your own logic |
| When to choose | Simple reading and writing of catalogs and documents | You need custom processing: calculations, checks, a response built for the site |
| Setup | Enable the standard OData interface composition and publish the database | Create an “HTTP service” object, write handlers, publish |
| Downsides | Exposes the 1C structure as is, heavy selections, awkward names | You write and maintain code |

A practical rule: **for catalog and stock a custom HTTP service is usually more convenient** with a compact response, while OData fits quick prototypes and administrative tasks.

## OData: a Python reading example

Once OData is enabled and the database is published, objects are available at an address like `http://server/base/odata/standard.odata/Catalog_Номенклатура`.

```python
import requests

BASE = "https://example.com/base/odata/standard.odata"


def items(top: int = 10) -> list[dict]:
    r = requests.get(
        f"{BASE}/Catalog_Номенклатура",
        params={"$format": "json", "$top": top},
        auth=("integration", "password-from-a-secret-store"),
        timeout=20,
    )
    r.raise_for_status()
    return r.json()["value"]
```

Take the login and password from environment variables or a secret store, not from code. (The object name `Catalog_Номенклатура` is the catalog “Nomenclature” in the 1C configuration.)

## HTTP service: a method example

In the configurator you create an “HTTP service” object with a root URL and a template. The method handler returns a response with JSON:

```bsl
Функция ТоварыGET(Запрос)

	Данные = Новый Массив;
	// ... fill the data from the catalog ...

	Запись = Новый ЗаписьJSON;
	Запись.УстановитьСтроку();
	ЗаписатьJSON(Запись, Данные);

	Ответ = Новый HTTPСервисОтвет(200);
	Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	Ответ.УстановитьТелоИзСтроки(Запись.Закрыть(), КодировкаТекста.UTF8);
	Возврат Ответ;

КонецФункции
```

The method address is built as `http://server/base/hs/rootURL/template`. Check the syntax on your platform version.

## Security rules

- **Do not expose the database to the internet directly.** Put a reverse proxy (for example nginx) in front of 1C with HTTPS and IP restrictions to your site.
- **A separate integration user** with a minimal role: only the objects and rights the exchange needs.
- **HTTPS is mandatory.** With Basic authentication over HTTP the login and password travel in plain text.
- **Keep passwords and tokens out of code.** Use environment variables or a secret store.
- **Limit the response size:** pagination and limits so a single request cannot overload the 1C server.

## Reliability rules for the exchange

1. **Idempotency.** Give every order a unique identifier. If a request is sent twice, 1C must understand the order already exists instead of creating a duplicate.
2. **Queue and retries.** Do not write to 1C straight from the site's handler. Save the order on your side and pass it to 1C with a separate process that retries.
3. **Exchange status.** Keep a “sent to 1C” flag and time for each order. It lets you find lost orders and see failures.
4. **Do not block the user.** If 1C is unavailable, the site should still accept the order and send it later.
5. **Versions and compatibility.** When you change a response format, keep the old fields or version the methods (`/v1/`, `/v2/`).
6. **Logs.** Log every call and error, otherwise failure analysis turns into guessing.

## Common mistakes

- **Encoding.** Send and receive JSON in UTF-8 and state it in the header.
- **Heavy selections.** A “all products” request with attributes and stock hangs a session. Use pages and a separate stock method.
- **Sessions and licenses.** Every call uses a database session: check licensing and set timeouts.
- **Time zones and dates.** Pass dates in one format and one time zone.
- **After a configuration change.** Check that methods are published, rights are in place and the format has not changed.

## What next

If you need to connect 1C with a website, an online store, Telegram and other services, see [1C and accounting systems](/uslugi/1c/) and [Integrations and APIs](/uslugi/integracii-i-api/). A related topic: [sending messages from 1C to Telegram](/blog/otpravka-soobshchenij-iz-1s-v-telegram/).

## FAQ

### What is better for a website: OData or an HTTP service?

OData suits a quick prototype and administrative tasks. For a working exchange of catalog, stock and orders an HTTP service with a compact response is usually more convenient.

### Can I connect a website to 1C without direct internet access?

Yes, and that is the right way. Keep 1C in the internal network and call it through a proxy with IP restrictions or through an intermediary service that talks to 1C itself.

### How do I avoid duplicate orders?

Pass a unique order identifier and check it on the 1C side before creating a document.

### What if 1C is temporarily unavailable?

Accept the order on the site, keep it in a queue and retry the transfer until you get a confirmation.