I have been building FastBusiness API, an API that turns a business name into structured company profile data.
The core idea is simple:
Instead of manually searching the web for a company’s website, industry, sector, country, headquarters, identifiers, description, and source links, you can send a request to the API and get a structured business profile back.
But while building it, I started to notice something important.
Not everyone wants to start with an API request.
Some users are comfortable jumping straight into endpoints, headers, API keys, JSON responses, and documentation.
But a lot of people just want to type in a business name and see what happens.
So I added two new parts to the product:
- A free public trial search
- A no-code business search inside the dashboard
This update changed how I think about the first experience of an API product.
The problem with making an API too “API-first”
When you are building an API, it is easy to assume the documentation is the product experience.
You create endpoints.
You write example requests.
You show the response structure.
You add authentication instructions.
You explain rate limits, usage, pricing, and error codes.
That is all important.
But there is still a problem.
A user has to care enough to do all of that before they have seen the value.
For FastBusiness API, the value is not just that the endpoint works.
The value is what the user gets back.
If someone searches for a company and sees a useful business profile returned instantly, they understand the product much faster than they would by reading a long documentation page.
That is why I wanted to add a free trial search directly to the website.
Adding a free trial search
The free trial search is designed to be simple.
A visitor lands on the site, types in a business name, and gets matching business profiles.
No account required.
No API key required.
No setup required.
The goal is to reduce friction as much as possible.
Instead of telling people:
“FastBusiness API returns structured company data.”
I can now show them.
A user can search for a business and see fields such as:
{
"business_name": "Example Company",
"website_url": "https://example.com",
"business_type": "private",
"industry": "Software Development",
"sector": "Technology",
"headquarters": "Sydney, Australia",
"country": "Australia",
"short_description": "A short factual business description.",
"confidence_score": 0.94,
"sources": [
{
"title": "Company website",
"url": "https://example.com"
}
]
}
The public search is not meant to replace the API.
It is meant to help users understand the API faster.
That distinction matters.
The API is still the main product, but the trial search becomes the first layer of trust.
Adding a no-code search inside the dashboard
The second part I added was a no-code search inside the user dashboard.
This is for logged-in users who want to search or generate business profiles without writing code.
They can use the dashboard to test the data before integrating the API into their own system.
This helps with a few things:
- non-technical users can still use the product
- developers can test results before writing integration code
- users can understand what fields are returned
- the dashboard becomes useful instead of just being an account area
- users can move from no-code usage to API usage when they are ready
I think this is important because not every API customer starts as a developer.
Some people might be founders, analysts, operations people, sales teams, researchers, or students.
They might still need structured company data, but they do not necessarily want to start by reading API docs.
A no-code search gives them a softer entry point.
The architecture behind the idea
The public trial search and no-code dashboard search both sit on top of the same core business profile data.
The main API still handles the real structured access.
The system is built around business profiles that can include:
- business name
- website URL
- business type
- LinkedIn URL
- ABN or ACN where available
- stock ticker and exchange where available
- employee count
- sector
- industry
- short description
- headquarters
- country
- confidence score
- source links
The API side is protected with headers like:
X-User-Email: user@example.com
APIKEY: sk_example_key
Then the main profile endpoints can be used for searching, retrieving, generating, refreshing, and checking generation job status.
But the no-code side gives users an easier path into the same concept.
Instead of starting with this:
curl -X GET "https://fastbusinessapi.com/api/businesses/search/?q=canva" \
-H "X-User-Email: user@example.com" \
-H "APIKEY: sk_example_key"
A user can start with this:
Search: Canva
That is a much easier first step.
Why this matters for API products
This update made me realise that an API product needs more than just working endpoints.
It needs a good first experience.
For developers, that might be a quick start guide.
For non-technical users, that might be a search box.
For founders, that might be a live demo.
For analysts, that might be a dashboard.
The same product can have multiple entry points.
I used to think of the API as the full product.
Now I see the API as the engine.
The public trial search and no-code dashboard are the doors into that engine.
What I learned from building this
The biggest lesson is that reducing friction matters a lot.
A user should not need to understand your whole system before they can see value.
For FastBusiness API, I want users to be able to move through the product like this:
- Search a business for free
- See the kind of data returned
- Create an account if it is useful
- Use the no-code dashboard to test more
- Move into the API when they are ready to integrate
That flow feels much better than:
- Create an account
- Generate an API key
- Read the docs
- Write a request
- Debug headers
- Finally see the result
The second flow might be normal for APIs, but it is not always the best first experience.
What I would improve next
There are still a few things I want to improve.
I want the trial search to feel faster and cleaner.
I want better empty states when no business is found.
I want users to see enough data to understand the product, but not so much that the public search gives away the entire value.
I also want the dashboard version to feel more like a real business research tool, not just a basic search page.
Some ideas I am thinking about:
- saved searches
- recently viewed businesses
- business comparison
- confidence breakdowns
- better source previews
- field-level freshness indicators
- export options
- simple enrichment workflows
The long-term goal is to make FastBusiness API useful for developers and non-developers.
Developers should be able to integrate it into their apps.
Non-technical users should be able to search, explore, and understand company data without needing to code.
Final thoughts
Adding a free trial search and no-code search made the product feel more complete.
It is still an API-first product, but now users do not have to start with the API.
They can start with a simple search.
That one change makes the product easier to explain, easier to test, and easier to trust.
For anyone building an API product, I think it is worth asking:
Can users experience the value before they touch the docs?
If the answer is no, there might be an opportunity to build a better first experience.
That is what I am trying to do with FastBusiness API.
You can check it out here:
Top comments (0)