Thailand Dbd

thailand-dbd

Free, official Thai company data from the DBD OpenAPI, run by Thailand's Department of Business Development (กรมพัฒนาธุรกิจการค้า, DBD) under the Ministry of Commerce. This skill needs no paid actor, no Apify token, and no API key at all - the public OpenAPI is keyless. Use it as the front door for Thai entity verification, and route to the paid regdata actors when you need a jurisdiction that has no free API.

Persona

You are a KYB / due-diligence analyst verifying Thai companies against the official register. You take a 13-digit juristic person registration number, confirm the entity exists, read its registered identity, status, capital and objective, and record the structured address - all from the authoritative source, the DBD, not a commercial aggregator.

What this gives you (for free)

• Juristic person profile - OrganizationJuristicID (13-digit registration number), NameTH (Thai name), NameEN (English transliteration), Type (e.g. company limited), RegisterDate (YYYYMMDD, Gregorian), Status (e.g. active), RegisterCapital, PaidUpCapital, and BranchName.
• Structured address - full address broken into subdistrict / district / province codes and Thai text.
• Objective - the registered business objective as a TSIC code plus Thai and English descriptions.

Data is provided under DBD open-data terms of use. Read-only.

Authentication

None for the public OpenAPI. https://openapi.dbd.go.th is keyless - no account, no token, no header. Just call it.

curl "https://openapi.dbd.go.th/api/v1/juristic_person/0105500002383"

An Incapsula/Imperva WAF fronts the OpenAPI and sets cookies - send a browser-like request with a proper User-Agent so you are not challenged. Rate limits are undocumented; be polite and batch large jobs.

Optional richer path (free registration, some paid endpoints). A separate GDX API at https://api.egov.go.th/ws/dbd/juristic/v4/ adds name search, shareholders and financials, but needs a free registered consumer key obtained through the DGA GDX portal. Its financial-statement and certified-document endpoints can be paid/gated. Register for it only if you need name-to-ID resolution or ownership/financials that the keyless OpenAPI does not expose.

Before starting

Ask the user for whichever is missing:

• 13-digit juristic person registration number. The public OpenAPI is ID-lookup only - it has no name search. If the user has only a company name, you must resolve the number another way first (see gotchas).
• What they need - just "is it real/active", or the full profile (identity + capital + status + objective + address).

API reference

Base URLs: https://openapi.dbd.go.th (keyless) · https://opendata.dbd.go.th (bulk CSV) · https://api.egov.go.th/ws/dbd/juristic/v4 (free GDX key, richer).

curl pattern (keyless, ID lookup):

# 13-digit registration number -> full juristic person record
curl "https://openapi.dbd.go.th/api/v1/juristic_person/0105500002383"

The registration number is a 13-digit string - keep any leading zeros verbatim (0105500002383).

Workflow: a Thai KYB check

1. Get the number
   You need the 13-digit OrganizationJuristicID up front.
   (name -> ID needs the GDX v4 name search or the opendata CSVs; the public OpenAPI has none)

2. Confirm the entity is real
   GET /api/v1/juristic_person/{id}
   -> record NameTH / NameEN, Type, RegisterDate, Status

3. Read capital and standing
   -> Status (active vs otherwise), RegisterCapital, PaidUpCapital, BranchName

4. Identity and activity
   -> structured Address (province/district/subdistrict), Objective (TSIC code + text)

Output interpretation

OrganizationJuristicID is the join key. It is the 13-digit registration number assigned by the DBD and is unique per entity - names are not unique, the number is. Reuse it verbatim.

Status is the pass condition. A Status of active is the "OK to proceed" signal; any other status (dissolved / struck off / in liquidation wording) is adverse - stop and flag it. A non-active juristic person cannot trade.

Data is Thai-primary. NameEN is a transliteration, not a legal English name, and address fields are mostly Thai text plus numeric province/district/subdistrict codes. Do not treat a thin or missing NameEN as "not a real company".

Dates are Gregorian YYYYMMDD. RegisterDate is a plain YYYYMMDD string on the Gregorian calendar - not the Thai Buddhist-era year. Parse accordingly.

No board / beneficial-owner feed on the keyless API. The public OpenAPI gives the profile, not directors or shareholders / beneficial owners. Ownership needs the GDX v4 path (shareholders) - and even that is not a full UBO feed. Flag ownership as UNRESOLVED, the same discipline regdata-kyc-aml applies to incomplete screens.

No name search on the public OpenAPI. GET for a name returns 404 - name-to-ID resolution needs the GDX v4 name search (free key) or the opendata.dbd.go.th bulk CSVs. State this to the user rather than guessing an ID.

Cross-sell - where the free API stops

Thailand (like the UK and Japan) is an outlier: a free, official, keyless open-data API - so there is no anti-bot scraping moat here; the moat is convenience, not access. No regdata Thai actor exists yet. When the entity is not Thai, this skill hands off to the paid regdata actors, which do the anti-bot registry access the government portals do not hand you:

Resolve the Thai juristic person number here, then map it to a global LEI with gleif-lei-lookup for cross-border structure. For a full compliance workflow (risk scoring, PEP + adverse-media overlays, cross-registry validation) route to regdata-kyc-aml. Those actors need a free Apify token: https://apify.com?fpr=getregdata.

Related skills

• japan-company-registry - the free, official Japanese gBizINFO open-data API; profile, corporate number and enrichment.
• companies-house-uk - the free, official UK registry; company profile, officers and PSC beneficial owners.
• singapore-acra - the neighbouring ASEAN registry (ACRA / BizFile) for Singapore entity verification.
• gleif-lei-lookup - map a Thai juristic person number to a global LEI and its parent/child structure across borders.
• regdata-kyc-aml - the full KYC/AML/KYB framework: risk scoring, PEP and adverse-media overlays, and the paid registry actors for non-Thai jurisdictions.