Benin (BJ) — internal licensing notes

Source research, 2026-09-17 — structural fit check, not primarily a licensing question

Confirmed: Benin has no operational postal code system. Addressing relies on descriptive information — department and commune/municipality, locality name, street name or PO Box ("boîte postale"), and proximity to landmarks — not postcodes.

What was checked

• La Poste du Bénin S.A (laposte.bj) — the national postal operator's own site was fetched 2026-09-17. It references "Poste aux lettres" (mail), "Colis postaux" (parcels), and a PO-box payment service ("Paiement boîte postale"), but contains no mention of postal codes or any coding system for addresses. Consistent with a PO-box-based addressing regime, same shape as several other West/Central African francophone countries already in this catalogue (Guinea, Republic of the Congo, Senegal-adjacent patterns) — but unlike those, Benin has no PO-box-tied numeric code at all, not even a 3-digit one.
• Wikipedia, "List of postal codes" (2026-09-17): Benin's row reads format = "no codes", with no note about a planned or announced system — unlike Libya (2019 project noted) or Syria ("a 4-digit system has been announced, status unknown"). This is a flatter "no codes, no known rollout" case than either of those two.
• GeoPostcodes.com (2026-09-17), a community aggregator: states outright "There is no postal code system in this country" / "Benin does not utilize a standardized postal code system for mail delivery or location identification." Its own product for Benin is an administrative-hierarchy/locality dataset (Region 1–4 + Locality + coordinates), not postal codes — same non-official-placeholder pattern already seen for Zimbabwe and Syria in this catalogue: aggregators selling admin/locality data dressed as a "ZIP code" product because none exists.
• codepostalmonde.com/benin: returned HTTP 403 (blocked), not independently verifiable in this pass. Not needed — two independent primary/semi-official sources (La Poste du Bénin's own site, Wikipedia) plus GeoPostcodes already agree without it.

GeoNames

• Postal export: https://download.geonames.org/export/zip/BJ.zip → plain 404 (confirmed 2026-09-17, curl -sI). Consistent with there being no system to export — same signature as Libya, Syria, and Zimbabwe's zip exports elsewhere in this catalogue.
• Main gazetteer dump: https://download.geonames.org/export/dump/BJ.zip → 200 OK, 166,519 bytes, extracts to BJ.txt (5,978 total rows). This is a real, fetchable candidate for a future free locality-only build, same product used for Bolivia/Ethiopia/Uganda/Libya/Zimbabwe/Syria in this catalogue.
  • Feature class breakdown: P (populated places) 3,760 · H (hydrographic) 1,331 · A (admin boundaries) 631 · T (hypsographic) 128 · S (spot/facility) 86 · L (parks/area) 39 · V (vegetation) 3.
  • Feature class P (populated places): 3,760 rows.
  • admin1 (department) coverage among P rows: 12 real numeric buckets present (07–18 excluding a gap, see table below), ranging from 829 (bucket 08, Atakora) down to 6 (bucket 14, Littoral), plus 14 rows on GeoNames' reserved 00 bucket ("general features where no specific adm1 code is defined", per GeoNames' own readme) — same disposition as Libya/Syria: these would ship with blank admin_name1/admin_code1 rather than guessed.
  • admin2 coverage among P rows is thin: only 315 of 3,760 (8.4%) carry an admin2 code. A future build's admin_name2/admin_code2 fields would be sparse, not a data-entry gap — the source itself rarely populates this tier for Benin.

ISO 3166-2:BJ crosswalk (needed for any future build)

Confirmed via Wikipedia's ISO_3166-2:BJ page (2026-09-17) — 12 departments, all with real alpha ISO codes:

Spelling trap for a future build: GeoNames labels two of its twelve BJ admin1 buckets differently from the ISO/Wikipedia spelling — BJ-AK = "Atacora" (ISO) vs. "Atakora" (GeoNames admin1CodesASCII), and BJ-KO = "Couffo" (ISO) vs. "Kouffo" (GeoNames). Both are the same single department each (not a Damascus/Rif-Dimashq-style split into two real administrative units) — a c/k transliteration variant only. A name-based join must map by the numeric admin1 bucket code (BJ.08, BJ.12), not by string-matching the department name, or these two departments' rows will silently fail to match. Otherwise the crosswalk is clean: all 12 GeoNames numeric buckets map one-to-one to all 12 current ISO alpha codes, no missing or extra departments, no reform-era mismatch (Benin's department count and boundaries have been stable since the 1999 split from 6 to 12 departments — no recent reorganisation like Angola's or Ethiopia's).

Current repo state (verified, not assumed)

• datasets/bj/datapackage.yml: data_available: false — accurate.
• R2 placeholder path declared: https://postal.datahub.io/bj/bj.csv, declared bytes: 158 in the datapackage — matches the 13-column header size seen for other not-yet-built countries in this catalogue (SY was 158 bytes too). Not independently re-fetched over the network in this pass (out of scope per the task's instruction not to touch R2), but the datapackage's own declaration is internally consistent with "header row only, no data".
• No .licensing-notes.md existed for bj before this pass.

Verdict

Benin has no postal code system, and — unlike Libya or Syria — no evidence was found of any announced or in-progress rollout. This is closer to a permanent structural fact (same class as Bolivia, Curaçao, Côte d'Ivoire, Zimbabwe pre-locality-build) than to Libya/Syria's "stalled but announced" status, though absence of a found announcement is not proof none exists — a future re-check should specifically search for any ARCEP-Bénin (Autorité de Régulation des Communications Électroniques et de la Poste) postal-modernisation initiative, since that regulator's own Wikipedia page turned up in search results but was not fetched in this pass.

Free-locality-directory candidate: YES, same shape as Bolivia/Ethiopia/Uganda/Libya/Zimbabwe/Syria. GeoNames' main gazetteer dump is live, returns 3,760 populated places, covers all 12 departments with a clean (modulo the Atakora/Kouffo spelling trap above) ISO 3166-2:BJ crosswalk, and is licensed CC BY 4.0 — the same terms already used for the equivalent builds elsewhere in this catalogue. No incompatible-licence signal was found (GeoNames CC BY 4.0 throughout; no OSM/ODbL involvement in this candidate source, no scraping-prohibition terms encountered on any site checked).

No licence_status block is added here — there is no data shipped yet to gate. data_available is left unchanged (false) since this is a research-only pass; datapackage.yml was not modified. Nothing was uploaded, committed, or catalogued; no R2 or git operation was performed, per the task's explicit research-only scope.

Recommended next step: if/when a build pass is picked up for BJ, follow the Libya/Zimbabwe/Syria build_postal_codes_product.py pattern — GeoNames main dump, feature class P, postal_code left empty on every row (documented as the catalogue convention for no-postal-code countries, not a gap), admin1 joined by numeric bucket code (not name string) to avoid the Atakora/Kouffo trap, admin2 left blank on the ~92% of rows where the source itself has none. Before that build, re-check laposte.bj and search specifically for an ARCEP-Bénin postal-code modernisation announcement, in case a rollout exists that this pass missed — a live official source would be strictly preferable to GeoNames per this project's GeoNames-is-fallback-not-default rule.

Build, 2026-09-17 — local build only, not published

Built following the Libya/Syria build_postal_codes_product.py pattern (csv module only, no pandas). Source files fetched fresh into datasets/bj/sources/: BJ.zip (166,519 bytes, https://download.geonames.org/export/dump/BJ.zip), extracted to BJ.txt (5,978 total rows); geonames_admin1CodesASCII.txt and readme.txt fetched from the same GeoNames dump export tree.

Row count: filtered to feature class P (populated places) — 3,760 rows, matching the research pass exactly. Feature-class breakdown reconfirmed: P 3,760 · H 1,331 · A 631 · T 128 · S 86 · L 39 · V 3.

ISO department coverage: 12/12. Joined on GeoNames' own numeric admin1 bucket code (BJ.07–BJ.18), not on the department name string, specifically to sidestep the Atakora/Kouffo spelling trap — verified in geonames_admin1CodesASCII.txt: BJ.08 = "Atakora" (GeoNames) vs. "Atacora" (ISO, BJ-AK), BJ.12 = "Kouffo" (GeoNames) vs. "Couffo" (ISO, BJ-KO). The build asserts both GeoNames spellings explicitly (assert_atakora_kouffo_trap) so an upstream rename would be caught rather than silently changing the crosswalk's assumptions. All 12 departments are present in the output with their correct row counts (Alibori 447, Atacora 829, Atlantique 162, Borgou 809, Collines 235, Couffo 212, Donga 495, Littoral 6, Mono 110, Ouémé 82, Plateau 65, Zou 294).

Blank admin_code1: 14 rows, all sitting on GeoNames' reserved admin1 bucket 00 ("general features where no specific adm1 code is defined"). Left blank rather than guessed, same disposition as Libya (22 rows) and Syria (19 rows). postal_code is empty on every row of the 3,760 — Benin has no postal-code system, a structural fact, not a defect.

Validation: python3 build_postal_codes_product.py ran clean, all in-script assertions passed (row count, department coverage, no duplicate (place_name, latitude, longitude) triples, no leaked nan strings, accuracy empty on every row). frictionless validate datapackage.json, run from inside datasets/bj/data/, reports the bj resource VALID. The declared resource's rows (3,760) and bytes (186,571) match the actual written bj.csv exactly — validated the delivered artifact, not just the working copy.

Output: datasets/bj/data/bj.csv, datapackage.json, README.md, ATTRIBUTION.txt, bj.zip (52.2 KB). licence_status.decision is compatible (CC BY 4.0, GeoNames), channel: "postal-codes-r2".

This was a local build only. Nothing was uploaded to R2, no git commit or push was made, and _meta/catalog.json / datapackage.yml were left untouched, per the task's explicit instruction. Publishing (catalog entry, datapackage.yml update, R2 upload) remains a separate, not-yet-done step.