I built a company-verification API for the Gulf Market
Every global company-data API stops at Europe. Stripe's data products, OpenCorporates, the big aggregators — none of them cover Saudi Arabia, UAE, Kuwait, Qatar, Bahrain, Oman, or Lebanon. The data exists, but it's scattered across seven government portals, most of them Arabic-only, some permission-

Every global company-data API stops at Europe. Stripe's data products, OpenCorporates, the big aggregators — none of them cover Saudi Arabia, UAE, Kuwait, Qatar, Bahrain, Oman, or Lebanon. The data exists, but it's scattered across seven government portals, most of them Arabic-only, some permission-only. For a developer, "verify this Gulf company" means manually hunting through portals and PDFs. So I built the thing that should have existed. One endpoint: POST /api/v1/verify-company returns: { "country": "SA", It validates TRN/VAT format against each country's rules (Saudi 15 digits starting 3, UAE 15 starting 1, Kuwait/Bahrain 9, Qatar 10, Oman 8, Lebanon 5-8), surfaces risk heuristics from the name (offshore, generic-shell, newly-registered), and does it all through one deterministic contract. The raw key is shown to the user exactly once. From then on we store only: SHA-256(key + pepper) and a display prefix like "lb_test_..." Not the key itself. So a leaked key reveals nothing about the customer, and a lost key can never be recovered — you revoke it and mint a new one. This is the pattern Stripe and OpenAI use, and it's the whole game: the real key exists in exactly one place, the customer's clipboard. 400 malformed request Each one means a real thing. No vague 500s. If you're a developer integrating this, the error tells you exactly what to fix. Every call goes through a middleware that checks the key hash, enforces a per-key quota (500 calls on the founder tier), a per-key rate limit (60 req/min, derived from the usage log so it holds across serverless instances), and traces every request with an x-request-id. Email double opt-in (keys return 403 until confirmed), disposable-domain blocking, and per-IP caps. A squatted email can always be reclaimed by its real owner. This is the part I'd genuinely like the community to weigh in on. Today the API validates TRN/VAT format and returns risk heuristics. It does not query live government registries or sanctions lists. Every response carries this flag: { "registry_live": "not_queried_no_feed" } I chose to ship a tool that tells you exactly what it cannot verify rather than one that silently fakes "registered" — because if someone builds a compliance decision on a fabricated verdict, that's on the tool. The hard part is next: live registry verification. The Gulf data providers (CRIF / D&B Gulf, Kyckr) quote enterprise pricing (around 0.24 USD per lookup). At a consumer API price that wipes the margin out. So I'm stuck on the classic data-moat pricing problem — and I'd love to hear how other dev-tool builders have solved licensing expensive registry data. https://mena-biz-api-nassims-projects-08916750.vercel.app/**_ _** About 60 seconds: enter your email, click the sign-in link, create a key, then run curl: KEY="lb_test_" https://mena-biz-api-nassims-projects-08916750.vercel.app/api/v1/verify-company \ Founder offer: 500 free calls for the first 50 signups, no credit card. Site: https://mena-biz-api-nassims-projects-08916750.vercel.app/ This is build-in-public. I'll follow up with the live-registry pricing saga and whatever the community tells me.
Key Takeaways
- •Every global company-data API stops at Europe. Stripe's data products, OpenCorporates, the big aggregators — none of them cover Saudi Arabia, UAE, Kuwait, Qatar, Bahrain, Oman, or Lebanon
- •This story was reported by Dev.to, covering developments in the dev space.
- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.
📖 Continue reading the full article:
Read Full Article on Dev.to →


