Rejestry API to część platformy DebtStrike — sprawdzania kontrahentów i windykacji.Sprawdź firmę bez integracji →

Rejestry API → API REGON / GUS

API REGON / GUS

GET /v1/regon/{identifier}

Tożsamość, adres i PKD z rejestru REGON (GUS BIR). Dla jednoosobowych działalności, których BIR nie zwraca w komplecie, przewidziany jest fallback na CEIDG.

data: regon, nip, krs, name, entityType, active, address, pkd, endDate, provider (gus_bir albo ceidg).

Stan faktyczny: fallback CEIDG jest zaimplementowany, ale na produkcji nieaktywny — brakuje klucza do API CEIDG. Do czasu jego uzyskania provider zawsze wynosi gus_bir. Piszemy o tym wprost, bo obietnica źródła, którego nie ma, jest gorsza niż jego brak.

Kody PKD normalizujemy do jednego formatu (19.20.Z) niezależnie od tego, że GUS oddaje je jako 1920Z, a KRS z kropkami. To jeden z powodów, dla których warto brać dane przez jedno API zamiast z siedmiu.

Przykład zapytania i odpowiedzi

Tożsamość, adres i PKD podmiotu z rejestru REGON. W ścieżce może stać NIP, KRS albo REGON.

curl -s https://api.debtstrike.eu/v1/regon/7740001454 \
  -H "Authorization: Bearer ds_test_TWOJ_KLUCZ"

Zapytanie działa z kluczem testowym ds_test_. Taki klucz zwraca stałe, syntetyczne dane podmiotu testowego (NIP 7740001454, KRS 0000028860, REGON 610188201), nie dotyka rejestrów i nie zdejmuje ani jednej jednostki pakietu ("billed": 0). Każdy inny numer zwraca status: not_found, więc przećwiczysz też tę ścieżkę. Z kluczem ds_live_ zmienia się tylko klucz, a dane są prawdziwe.

{
  "status": "found",
  "data": {
    "name": "PODMIOT TESTOWY SPÓŁKA AKCYJNA (SANDBOX)",
    "nip": "7740001454",
    "regon": "610188201",
    "krs": "0000028860",
    "entityType": "legal",
    "address": { "street": "CHEMIKÓW", "building": "7", "flat": null,
                 "postalCode": "09411", "city": "PŁOCK",
                 "voivodeship": "MAZOWIECKIE", "county": "M. PŁOCK",
                 "commune": "M. PŁOCK" },
    "pkd": { "main": "19.20.Z",
             "description": "WYTWARZANIE I PRZETWARZANIE PRODUKTÓW RAFINACJI ROPY NAFTOWEJ",
             "division": "19" },
    "active": true,
    "endDate": null,
    "provider": "gus_bir"
  },
  "meta": { "billed": 0 }
}

Fragment odpowiedzi: koperta (apiVersion, requestId, subject, source, timestamps) jest opisana na stronie przeglądowej.

Pola odpowiedzi w data

Pole Typ Znaczenie
name string Nazwa podmiotu w rejestrze REGON.
nip, regon, krs string albo null Identyfikatory podmiotu. krs jest null dla podmiotów, których nie ma w KRS.
entityType string albo null legal dla osoby prawnej, natural dla osoby fizycznej, null gdy rejestr nie rozstrzyga.
address object Adres: street, building, flat, postalCode, city, voivodeship, county, commune. Kod pocztowy jest w postaci zwracanej przez GUS (w przykładzie bez myślnika).
pkd object main to kod przeważającej działalności w jednym formacie (19.20.Z), description to jego opis, division to dwucyfrowy dział.
active boolean Czy podmiot figuruje w rejestrze jako działający.
endDate string albo null Data zakończenia działalności, jeśli ją podano.
provider string gus_bir albo ceidg. Dziś zawsze gus_bir, bo fallback CEIDG jest na produkcji nieaktywny.

Odpowiedzi i błędy tego endpointu

HTTP Kod lub status Kiedy
200 found Podmiot znaleziony w rejestrze REGON.
200 not_found GUS odpowiedział, że nie ma takiego podmiotu.
200 unavailable GUS nie odpowiedział. To brak wiedzy, nie dowód braku podmiotu.
400 invalid_identifier Identyfikator nie jest NIP-em, KRS-em ani REGON-em (9 lub 14 cyfr z poprawną sumą kontrolną).
403 source_not_in_plan Klucz nie ma zakresu regon.

Pozostałe kody (401, 429, 500) są wspólne dla wszystkich źródeł i opisane w tabeli błędów. Błędy mają format application/problem+json (RFC 9457) z polami code i requestId.

Pozostałe rejestry w tym samym API

Wszystkie źródła mają tę samą kopertę, ten sam sposób uwierzytelniania i te same kody błędów:

Zanim wyślesz pierwsze zapytanie

Zasady wspólne dla wszystkich źródeł opisuje strona przeglądowa: uwierzytelnianie kluczem, koperta odpowiedzi, różnica między not_found a unavailable, rozliczenie zapytań i limity. Pełny kontrakt: /v1/openapi.json.

Uzyskaj dostęp do API →