Vet counterparties by INN without leaving the chat

The agent calls two DaData services at once. Through suggestions it looks companies up by INN, OGRN, BIC and corporate email, collects affiliated companies through founders and directors, pulls the OKVED and OKTMO reference books, resolves an address by coordinates and a city by IP. Through standardisation it parses addresses down to the apartment and brings phone numbers and personal names to a single format.

These two services are built differently, and the agent accounts for that. Suggestions answer a fuzzy string with a list of candidates: a query like OOO Romashka returns several, and taking the first one is not an option. So when vetting a counterparty the agent relies on an exact INN or OGRN, and flags a name match as a hypothesis. Standardisation, meanwhile, lives on a separate host and answers not with a list of candidates but with one parsed object: a string is either split into fields or marked as unparsed.

There is nothing to change in DaData: the service is a reference source, the agent sends a string and gets a parsed response back, creating and editing nothing. It writes only on your side — keeping the list of screened INNs and, on a regular run, reporting who has been liquidated, changed address or changed director since the last check. A registry status is presented as a registry record, not as proof that the company actually operates.

Usage is counted against the plan limits: 10,000 suggestion requests a day for free, while standardisation is billed separately at roughly 20 kopecks per address, so the agent sizes a bulk clean-up by volume up front and runs it in batches rather than firing the whole list at once. When the limit runs out or a company is not found in the registry, it says so directly instead of returning an empty line.