All changes in the CRM are made not through the screens but programmatically — over the management addresses that are the very language you speak with the agent. It sounds technical, but the essence is simple: the product has a set of commands by which the agent creates and edits data, while the interface only shows the result. Neither you nor the agent needs to know the commands by heart: the product tells what it can do by itself.
Why management over the API
An API (a program management address) is a way to do things by word-commands instead of clicks. For the product this is a matter of principle: this is exactly how the agent can perform hundreds of same-type actions without confusing anything, and this is exactly why the interface stays light and safe. The screen reads, management writes — and these two roles are deliberately kept apart.
Two kinds of access
The product has two different “passes”. The first is the ordinary sign-in to the interface: it grants reading only, and that is checked on the server, not in the browser. The second is the management key: only with it can the data be changed. The key travels in the request header — the agent presents it together with every command.
A side benefit is the honesty of the arrangement: even if the person at the browser really wants to change something, they cannot, because their pass does not allow it. And if there is no key at all, changes are simply refused — the product says so plainly, while reading keeps working.
The management key
The key is set once at installation — as a separate environment variable. What is stored on the server is not the key itself but its irreversible fingerprint: even looking into the settings, the key cannot be recovered. The check is made so the key cannot be guessed character by character from the response time. If the key must be changed, it is changed in the installation settings and the product restarts — the old one stops working at once.
A reference that explains itself
The main convenience for the agent: at one address it gets the full reference — what exists here, how to sign in, how lists and errors are arranged, which resources are available and where each description lies. The same place holds a short guide with typical sequences (“search first, then create”, “check the import without writing, then run it”), a table of error codes with explanations and a list of limits with concrete numbers. Put simply: knowing only the address and the key, the agent figures out the rest by itself — without reading code and without separately written instructions that go stale.
The limits in this reference are not invented: the numbers come from the product itself, so it never happens that the documentation promises one thing and the product does another.
Resource descriptions and the data structure
Every section has its own description: which fields exist, which values are allowed, which addresses to call, with a request and response example for each, which errors occur and what this section links to. The shared list of record kinds and the links between them is described separately — it shows how the data is arranged as a whole. There is not a single “secret” address: everything the product can do is described and matches reality.
If you created custom fields or custom objects, they appear in the descriptions too — immediately, without a restart. So the agent always sees the live picture of your base, not the stock one from the box.
Who exactly changed it
Together with a command the agent can name itself — by a short signature. Then the change history and the log entries show not a faceless “service” but a concrete name: “support agent”, “carry-over from the old base”. If there is no signature, the change is still recorded and attributed to the management agent. Thanks to this you can always tell whose edit it is — a human’s or a specific agent’s.
The live stream of changes
About changes the product itself reports to those watching the data: as soon as the agent corrects something, the open screens show it — without reloading the page. Agents receive this signal too when they need to watch for changes — so as not to overwrite a fresh human edit, for example. That is, the human and the agent see the same events — nobody works blind.
Public request intake — separate and narrow
Request intake from other people’s sites has its own very restricted pass. With it you can only create a request and nothing else: neither read the client base, nor change a contact, nor learn what is in it. This is done deliberately: the intake key inevitably sits in the page’s code and can leak, so its capabilities are cut to the minimum. The key can be replaced at any moment, and the old one stops being accepted at once. The address requests arrive at answers any wrong key with the same modest response — it gives nothing away about what is inside.
Limits and understandable errors
Management works by understandable rules, and all of them are named plainly. Lists are served in pages: 25 records by default, at most 100 — every list answers this way, so big exports are done as a separate export operation, not pulled in one page. The filter has sensible bounds: no more than 25 conditions and no deeper than three nesting levels — usually that is enough with a big margin. Repeated calls to the request intake are rate-limited, and the request volume is size-limited.
Error answers are arranged humanly, not as “error 500”. A wrong field value — a refusal listing all the problem fields with an understandable reason. An unknown value from a list — an answer naming the allowed ones. If something is missing — the answer says what exactly and with which number. And when the rights are insufficient, the answer explains that the management key is needed and where to find the command descriptions — it does not leave the agent guessing. All errors arrive in one format, so they are easy for both the human and the program.
What is available to the agent
Everything present in your build is available for management: the client base, the timeline, data quality, import and export, custom fields and objects, plus all the switched-on add-ons — leads, deals, money, marketing, communications, service. What is not in your build is not in the reference either: the agent will not go looking for what does not exist. Switched an add-on on — its capabilities appeared; switched it off — they vanished.
Next → Chat with the AI Agent