TinyCommand Asks One Question. The API Fills Twenty-Six.
One domain went in. Twenty-six fields came back, including a 43-item tech stack. Every one of them is a question the form no longer has to ask.
TinyCommand puts forms, workflows, a relational database, email templates and agents on one canvas, built from a plain-language description rather than assembled from five subscriptions. One of its less obvious properties is that a form can call an external API while somebody is still filling it in, read the answer, and decide what to ask next.
That sounds like a convenience feature. It is closer to a redesign of the form, and here is why.
We sent one domain to a company enrichment endpoint. This came back:
input: figma.com
72 leaf fields returned
38 populated
26 of them are things a form would otherwise ask for
Twenty-six questions you no longer have to put on the page, in exchange for one you were going to ask anyway.
Fair disclosure. You are on the Monid blog, Monid sells the endpoint that returned those fields, and TinyCommand is a content partner. TinyCommand is not in the Monid catalogue. The section near the end covers what breaks, because a third of the fields came back empty and that matters.
What does a form already know before it asks?
More than most forms behave as though they know.
The work email is a primary key
Somebody typing name@acme.com has already told you the company domain, and the domain is enough to retrieve the firmographics on almost any commercial record. Yet the standard B2B form asks for the email and then asks for company name, size, industry and country underneath it, as if the four were independent facts.
They are not independent. Three of them are derivable from the first one, and every derivable field you ask for is a field the user has to type while deciding whether your form is worth finishing.
Shorter forms are not the point, better ones are
The usual framing is that fewer fields raise completion rates. True, and it undersells the change.
The real gain is that a form which looks things up can spend its remaining questions on things it genuinely cannot know: budget, timeline, the specific problem, who else is involved in the decision. You are not just removing four fields, you are trading four low-value fields for two high-value ones and still ending up shorter.
How many questions does one answer replace?
Twenty-six, on the record we tested, and the shape of them is more interesting than the count.
What came back from one domain
identity name, legalName, domain
classification sector, industry group, industry, sub-industry
plus 10 descriptive tags
firmographic founded year, company type, private or public
size employee band "1K-5K", exact count 2,930
location street, city, state, state code, country, country code
presence logo url, linkedin handle, traffic rank
technology 43 detected technologies across 18 categories
A few of those deserve a second look. Classification arrives at four levels, so you can route on a coarse sector and report on a fine sub-industry without asking twice. Size arrives twice, as a band and as an exact number, which matters because the band is what your routing rules want and the number is what your reporting wants. And the 43-item technology list is not a field anybody would put on a form at all: no visitor is going to hand-enter their stack, so before enrichment that information simply did not exist.
That last one is the argument in miniature. Enrichment does not only replace questions, it returns things you could never have asked for.
One third of it was empty
The same call returned 72 leaf fields and populated 38. Thirty-four came back empty.
That is not a defect, it is what enrichment looks like. Coverage varies by company: a well-documented software firm fills in nearly everything, a regional contractor fills in a fraction. A form built on the assumption that every field arrives will render blank labels at a user who is watching.
The design rule that follows: treat every enriched field as optional, and never show a label until its value exists.
Read the field list before you design the page
The practical order is the reverse of how most teams do it. The usual sequence is to design the form, then look for an API that fills it, then discover halfway through that the field you built a routing rule around is populated on a minority of records.
Inspecting the endpoint first costs nothing and takes minutes. You get the complete field list, so you know what is even available, and running a handful of your own real domains through it tells you the thing the documentation cannot: what fills in for the companies you actually sell to. Coverage on a list of enterprise software firms and coverage on a list of regional manufacturers are different numbers, and yours is the only one that matters.
Do that first and the form design falls out of the answer. Fields that populate reliably can carry routing logic. Fields that populate sometimes can prefill but must stay editable and must degrade to a question. Fields that rarely populate should not appear at all, because a form that half works is harder to trust than one that never promised.
Why does looking it up mid-fill change the form?
Because the response arrives in time to change the next question, and that is a different capability from filling boxes in faster.
Branching is the actual feature
Post-submit enrichment can only decorate a record that is already written. A lookup that happens mid-fill can decide what the form asks next.
Enriched size says two thousand nine hundred employees, so the form asks about procurement and security review and skips the self-serve questions entirely. The technology list shows a competing product already installed, so the form asks about renewal timing instead of asking whether they have a solution today. Sector comes back regulated, so a compliance question appears that nobody else sees.
This is the piece of TinyCommand's form product that is hard to replicate by stitching tools together: a form that runs a workflow while it is being filled, calls an external API mid-question, and branches on what comes back. Their wider platform is built around that idea, with a node canvas behind the form and several hundred native integrations for the systems the record eventually lands in.
The boundary between the two layers
Stated plainly, because it is easy to blur: TinyCommand runs the workflow, and the tool layer is what that workflow calls. The form, the branching, the table the record lands in, the follow-up, all of that is the platform. The lookup that happens in the middle reaches outside it.
Monid is the OpenRouter for agent tools for that outward half: one key and one balance across the enrichment endpoints and everything next to them, so adding a second data source to a form is a parameter rather than a procurement cycle. Discovery and inspection are free, which means you can read exactly which fields an endpoint returns before you design a form around them. That is the tools half of models and tools being two separate integrations.
The billing shape matters here more than the rate, because a form calls the endpoint on a schedule nobody controls. Submissions arrive in bursts, and a seat or a monthly floor prices that badly in both directions: idle between campaigns, capped during one. Metered per call tracks the actual shape of the traffic, which is the argument in paying per call rather than holding a subscription applied to a form rather than to a pipeline. Current per-endpoint figures live at monid.ai/tools rather than in this sentence, for the same reason a printed rate goes stale without anybody noticing.
One cost worth naming separately: the lookups you make on abandoned forms. If the call fires on the email field, you pay for every visitor who types an address and leaves, and on a top-of-funnel form that can be most of them. Firing the lookup one field later, after the user has committed something else, removes most of that spend without changing what the finished form knows.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to take this company domain, return the firmographic fields, and tell me which ones came back empty.What breaks when the lookup sits inside the form?
Three things, and a form that ignores them is worse than one that never enriched at all.
The user is waiting
Post-submit enrichment can take as long as it likes. A mid-fill lookup happens with somebody watching the cursor, so it belongs on a field they are moving away from rather than on the one they are about to answer, and it needs a timeout with a defined fallback. The fallback is always the same: ask the question you were going to ask anyway.
The record may not exist
Coverage is not universal and the miss rate is real, as the empty third above shows. A form must handle three outcomes, not two: enriched, not found, and lookup failed. The last two look identical to the user and should both land on the plain version of the form.
The data can be wrong or stale
A company that moved office, an employee count from a hiring spike, an acquired brand still classified under its old sector. If you prefill a visible field, let the user correct it and record which values they changed. That correction log is the cheapest possible quality signal on the endpoint you chose.
For the mechanics of doing this from an address rather than a domain, turning an email into a full person profile covers that path, and gating a signup form on verification covers the check that usually belongs in front of it.
When should the enrichment wait until after submit?
Three cases where mid-fill is the wrong place for it.
When nothing branches on the answer
If the enriched fields only ever land in a database and never change a question, do it after submission. The user gains nothing from waiting and you have added a failure mode to the critical path for no benefit.
When the form is consumer-facing
Company enrichment assumes a company. A personal address returns nothing useful, and a form that visibly pauses to look up a consumer is spending latency to learn that there was nothing to learn.
When the workflow already owns it
If the record is going to move through a longer automation anyway, enrichment is a step in that workflow rather than a step in the form. The data layer for an automation workflow covers that case properly, including what it costs when it runs on every record rather than on every submission. The two are complementary: mid-fill enrichment shapes the conversation, post-submit enrichment fills the record.
Conclusion
One domain in. Seventy-two fields back, thirty-eight populated, and twenty-six of them things the form would otherwise have asked a human to type, including a technology list nobody would ever have filled in by hand.
And a third of the response was empty, which is the part to design around rather than the part to hide.
The short version: a form that can look something up mid-fill is not a shorter form, it is a form that gets to spend its questions on what it could not have known. TinyCommand runs that workflow. The lookup in the middle is what it calls out to.
FAQ
Is this just progressive profiling?
Related but not the same. Progressive profiling asks different questions across repeat visits, using what you already stored about a known contact. This works on the first visit and on a stranger, because the domain they typed is enough to retrieve the record. The two combine well: enrich on visit one, then use progressive profiling for what enrichment could not supply.
Do I have to tell the user I looked their company up?
You should, and it also converts better. A visible "we filled this in from your domain, correct anything that is wrong" reads as competence rather than surveillance, and it gets you the corrections. Silently prefilling a field the user never sees is the version that generates complaints, because the first time they notice is when something is wrong.
Which company enrichment API should I use?
It depends on coverage in your segment more than on field count, and the honest way to choose is to run twenty of your own domains through two candidates and compare how many come back populated. The buy versus build comparison works through the tradeoff on the person side, and the same method applies to companies.
Can I do this in n8n or a similar workflow tool?
For post-submit enrichment, yes, and the data layer for n8n covers how. Mid-fill is the harder case, because the form itself has to make the call and branch on the result before the next question renders. That is a property of the form builder rather than of the workflow engine behind it.
Last updated August 2026.
