Maintained Spanish company history and monitoring for KYB platforms

Your primary provider verifies a Spanish company. BORME API adds the published BORME history: a traceable event timeline, officer and brand candidates, and change delivery for the companies you choose to watch.

Honest scope, first. BORME-A does not print tax IDs, cap tables or financial statements. We are not primary verification. A NIF, registry sheet, legal name or OEPM name can produce a sourced candidate, not an assertion that every identifier belongs to one company. NIF mappings state source and confidence; other candidate links retain their source reference and matching caveat. Unresolved and ambiguous candidates remain explicit.

You pay for the maintained operational layer

The notices are public. The integration pays for continuous acquisition, historical normalization, conservative entity-resolution candidates, indexed company history, replay and signed change delivery — with source references and ambiguity preserved instead of pushed into your application.

What the integration adds

Data	Depth
Published event timeline: appointments, terminations, capital operations, address changes and published insolvency phases	typed events with a BOE source link and act number
Company snapshot: a reconstruction from publication history — status, officers, capital and address where published	clear about publication scope, not a substitute for registry documents
People and brands: officer roles and OEPM names as candidate relationships	source references, ambiguity and the stated name-matching caveat travel with the answer
Change delivery: signed webhook or email when a watched company receives a new published event	operated from the daily publication workflow
Risk signals and profile: transparent rule outputs over the published history and declared external sources	factorized output, not an opaque decision
As-of view: what the published BORME history showed by that date	`GET /v1/companies/{slug}?as_of=2022-03-01`

Joining: candidates first, then your verification

Use these evidence-bearing inputs in order of strength:

GET /v1/companies/by-nif/{nif} — a sourced mapping where one exists; a 404 means "not mapped", not that the company does not exist.
registral.hoja (registry sheet, e.g. M 507991) — an identifier appearing in the published notice. It is valuable evidence, but the response still describes the publication basis.
company_slug — our deterministic normalization of the legal name; resilient to accents, punctuation and suffix variants (S.L./SL).
Name + province + incorporation date — a candidate set to review when stronger published identifiers are unavailable. Homonyms remain ambiguous.

GET /v1/companies/by-nif/A46103834  → snapshot by tax ID (incl. nif_source)
GET /v1/companies/{slug}            → state derived from observed history
GET /v1/companies/{slug}/events     → full timeline
GET /v1/companies/{slug}/network    → companies sharing officers
GET /v1/people/{name}/roles         → cross-company officer graph

Why teams integrate instead of rebuilding it

Official-source provenance: every normalized event keeps the BOE source link, gazette issue and act number.
Maintained processing: ingestion, normalization, entity-resolution candidates, replay and delivery are operated as one layer.
Explicit uncertainty: NIF mappings expose source and confidence; other links expose their source reference and caveat, while ambiguity is not silently collapsed.
Typed English JSON — no Spanish-gazette expertise needed on your team.

Integration paths

Evaluate today (no call needed): free key by email at get a free key, OpenAPI docs at api.bormeapi.com/docs, pay-per-event sandbox via the Apify actor ($1/1k events).

Volume / white-label: flat-fee full feed with webhook delivery and resale rights — write to [email protected].

Explore the API Talk to us