1C integration and custom solutions

APIs for 1C

An API gives mobile apps and partners a stable 1C contract without exposing configuration internals.

Discuss this directionContact form

Tell me the goal, stack constraints, and timeline — I reply on Telegram.

An API gives mobile apps and partners a stable 1C contract without exposing configuration internals. I design HTTP services and, when needed, an intermediary facade with versions, authorisation, and conventional JSON.

Scope includes resources, externalId, validation, idempotent commands, rate limits, OpenAPI, and request logs without secrets. Acceptance tests documentation from a clean client, repeats, denied roles, old versions, and 1C outages. Errors provide a safe log correlation code, and contract changes remain compatible or receive a new version.

Acceptance criteria

Done when

  • Agreed entities sync with externalId and no duplicates on retry
  • Exchange journal shows object, result, and attempt
  • Failure paths are visible to operators

Deliverables

  • API/contract notes + mapping table
  • Staging exchange runbook

Out of scope

  • 1C accounting-policy changes
  • Production 1C upgrades without change windows

Assumptions

  • Test infobase and a 1C contact for metadata

The final acceptance checklist is confirmed in the brief or contract; the list above is a scope alignment guide.

Ballpark estimate

Scope size
Extras

FAQ

Tap a question to expand the answer.

REST or OData?

OData quickly exposes standard entities inside a trusted environment. A REST facade gives external consumers better model, permission, and compatibility control.

Is an intermediary database required?

Not always. It helps with caching, queues, and traffic peaks but adds synchronisation rules that must be designed.

Discuss this directionContact form

Tell me the goal, stack constraints, and timeline — I reply on Telegram.

View full service page