Forem: Peter

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Peter — Sat, 18 Apr 2026 07:03:35 +0000

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Published April 18, 2026 | 5 min read

We just scanned 111 e-commerce domains and found a staggering truth: 93% of UCP profiles cannot complete AI agent purchases. Not because they don't have UCP files, but because they fail at the 3 critical steps that actually matter for agentic commerce.

The Data Behind the 93%

Our AI Readiness Index scanned 111 reachable domains across fashion, home decor, beauty, SaaS, and marketplaces:

72 domains (65%): Zero UCP presence at all
35 domains (31.5%): Have UCP files but are functionally broken
4 domains (3.6%): Have structural issues
0 domains: Are actually AI-agent ready

Among the 35 stores that technically "pass" UCP validation (Grade C), 100% share the same 3 fatal failures. This is where the real problem lies.

The 3 Failures That Break AI Commerce

1. Missing `signing_keys` - 20% of all stores

{
  "ucp_version": "1.0",
  "signing_keys": []  // ← EMPTY OR MISSING
}

Why it matters: Without cryptographic signing keys, AI agents cannot verify that your UCP manifest is authentic and hasn't been tampered with. This is a security requirement for any transaction.

Impact: Agents will refuse to interact with your store, period.

2. Missing `payment_handlers` - 23% of stores with UCP

{
  "services": {
    "checkout": {
      "type": "rest",
      "uri": "https://yourstore.com/checkout",
      "payment_handlers": []  // ← EMPTY OR MISSING
    }
  }
}

Why it matters: Payment handlers tell AI agents which payment methods you accept (credit cards, PayPal, Apple Pay, etc.). Without them, agents have no idea how to complete a purchase.

Impact: AI agents can discover your store but cannot buy from you.

3. Missing `return_policy` schema - 49% of all stores

{
  "organization": {
    "name": "Your Store",
    "return_policy": {
      "type": "object",
      "properties": {}  // ← MISSING REQUIRED FIELDS
    }
  }
}

Why it matters: Return policies are trust signals for AI agents. They need to know your return terms to recommend your store to users and handle post-purchase issues.

Impact: AI agents cannot display your trustworthiness, reducing conversion likelihood.

The "Detected" ≠ "Ready" Trap

Most UCP validation tools (including our own basic checks) only answer one question: "Is there a .well-known/ucp file?"

They don't answer the questions that actually matter:

✅ Can agents cryptographically verify your manifest?
✅ Can agents process payments at your store?
✅ Can agents display your trust signals?

Stores like Allbirds, Brooklinen, and Fashion Nova all pass basic UCP detection but fail at these critical levels. They're "detected" but not "transactable."

Real-World Example: BigCommerce Bug

We found a platform-wide issue affecting BigCommerce merchants:

{
  "services": {
    "dev.ucp.shopping": {
      "type": "rest",
      "uri": "https://store.mybigcommerce.com/api/ucp",
      "spec": {}  // ← MISSING SPEC FIELD
    }
  }
}

Three BigCommerce domains shared identical UCP_INVALID_SERVICE errors due to missing spec fields. This isn't merchant error - it's a platform implementation issue.

What This Means for AI Commerce

The 93% broken rate isn't just a statistic - it's a barrier to the $15T e-commerce market becoming AI-accessible.

For brands: You have a first-mover advantage right now. Fix these 3 fields and you'll be in the top 7% of AI-ready stores.

For agencies: Your clients' UCP profiles are likely broken even if they "pass" validation. You need to check these 3 critical areas.

For platforms: The current UCP implementation guidance is insufficient. Platforms need to enforce these 3 requirements at the validation level, not just the presence level.

Fix These in 15 Minutes

These aren't complex architectural changes. They're simple field additions:

Add signing keys from your SSL certificate
List accepted payment methods in payment_handlers
Define return terms in the return_policy schema

The tools exist to validate these properly - most just don't yet.

The Market Opportunity

Right now, the gap is enormous:

0% of marketplaces have working UCP
Only 31.5% of DTC brands even have UCP files
Of those, effectively none are actually AI-transactable

This creates a massive opportunity for the first platforms, agencies, and tools that solve these 3 fundamental problems.

Data from UCPtools AI Readiness Index - 111 domains scanned April 13, 2026. Scan methodology: Serper API discovery + targeted validation. All numbers from actual scan reports.

Test your store's UCP profile: https://ucptools.dev/directory?utm_source=devto&utm_medium=article&utm_campaign=202604 ?utm_source=dev.to&utm_medium=article&utm_campaign=202604

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

Peter — Sat, 18 Apr 2026 06:52:38 +0000

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

For compliance teams and credit risk analysts monitoring Austrian insolvency proceedings, the traditional path has been fraught with obstacles. The official Ediktsdatei system requires an expensive IWG government license, creating significant barriers for smaller firms, startups, and independent researchers who need access to critical insolvency data.

The Problem: IWG License Barrier

Austrian insolvency data is officially published through the Ediktsdatei system operated by the Austrian Courts. However, accessing this data programmatically traditionally required:

IWG License Application: Complex government approval process
Costly Subscription: Annual fees that can run into thousands of euros
Technical Limitations: Direct API access often restricted or unavailable
Geographic Restrictions: Some data may be location-limited

This barrier has left many compliance professionals forced to either:

Pay for expensive third-party services
Manually monitor court publications
Go without critical insolvency monitoring entirely

The Solution: Ediktsdatei Scraper on Apify

The Ediktsdatei scraper on Apify provides programmatic access to Austrian insolvency proceedings without requiring an IWG license. This democratizes access to critical compliance data that was previously locked behind bureaucratic and financial barriers.

Key Features

# Example: Get recent insolvency filings
from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")
run_input = {
    "keywords": ["Insolvenz", "Konkurs", "Sanierung"],
    "dateFrom": "2024-01-01",
    "maxResults": 100
}

run = client.actor("minute_contest/austria-ediktsdatei-scraper").call(run_input=run_input)

What you get:

Structured Data: Court decisions, creditor information, asset details
Real-time Monitoring: Track new filings as they're published
Historical Data: Access to past proceedings for trend analysis
Multi-Jurisdiction: Coverage across Austrian regional courts
Cost-Effective: Pay-per-use pricing starting at $0.005 per result

Use Cases for Compliance Teams

1. Credit Risk Assessment

Monitor Austrian companies showing signs of financial distress before it appears in credit reports. Early detection of insolvency proceedings allows for proactive risk mitigation.

2. Supply Chain Risk Management

Track your suppliers' financial health to prevent disruptions to your operations. Insolvency monitoring helps identify at-risk vendors before they fail.

3. Due Diligence for M&A

Conduct thorough background checks on Austrian target companies by reviewing their insolvency history and current proceedings.

4. Competitive Intelligence

Monitor industry competitors for financial distress signals that may create market opportunities or risks.

Technical Implementation

Basic Usage

import pandas as pd

# Fetch recent insolvency data
actor_client = ApifyClient("YOUR_API_TOKEN")
results = actor_client.dataset("YOUR_DATASET_ID").list_items()

# Analyze trends by court
df = pd.DataFrame(results)
court_counts = df['court'].value_counts()
print("Insolvency filings by court:")
print(court_counts)

Advanced Monitoring

Set up automated monitoring for specific companies or industries:

# Monitor specific companies
monitoring_list = [
    "Unternehmensname GmbH", 
    "Industrie AG",
    "Handels KG"
]

# Filter results for monitored companies
filtered_results = [
    item for item in results 
    if any(company in item['debtor_name'] for company in monitoring_list)
]

Comparison with Alternatives

Solution	Cost	License Required	Real-time Data	Historical Data
Ediktsdatei Scraper	$0.005/result	None	✅	✅
IWG Direct Access	€2,000+/year	Required ✅	✅	✅
Commercial Vendors	€500+/month	Varies	✅	✅
Manual Monitoring	€0 (time cost)	None	❌	Limited

Compliance Benefits

6AMLD Compliance

The upcoming 6th Anti-Money Laundering Directive (effective July 2027) requires enhanced due diligence on beneficial owners and risk assessment. Austrian insolvency data provides critical signals for:

Enhanced Due Diligence: Identifying high-risk entities
Ongoing Monitoring: Tracking changes in corporate structure
Source of Wealth Verification: Understanding financial history

Regulatory Reporting

Insolvency data feeds into various regulatory reporting requirements including:

Suspicious transaction reporting
Enhanced customer due diligence
Risk assessment documentation

Getting Started

Create Apify Account: Free tier available
Get API Token: Generate from your Apify dashboard
Deploy the Actor: One-click deployment of Ediktsdatei scraper
Configure Your Query: Set keywords, date ranges, and filters
Automate Monitoring: Set up scheduled runs for ongoing monitoring

First Run Example

# Configure your first scraping run
run_input = {
    "keywords": ["Konkurs", "Insolvenz", "Sanierungsplan"],
    "dateFrom": "2024-01-01",
    "dateTo": "2024-12-31",
    "maxResults": 50,
    "includeDetails": True
}

# Execute the scrape
run = client.actor("minute_contest/austria-ediktsdatei-scraper").call(run_input=run_input)

# Monitor progress
print(f"Run status: {run['status']}")
print(f"Items collected: {run['stats']['items']}")

Cost Analysis

The pay-per-use model makes this solution highly cost-effective:

Small Scale: 100 results/month = $0.50
Medium Scale: 1,000 results/month = $5.00
Large Scale: 10,000 results/month = $50.00

Compare this to traditional IWG license fees of €2,000+ per year, and the value proposition becomes clear.

Limitations and Considerations

Public Data Only: Only covers officially published insolvency proceedings
Update Frequency: Dependent on court publication schedules
Language: Most documents are in German
Data Completeness: Some details may be redacted or incomplete

Conclusion

The Ediktsdatei scraper on Apify removes the IWG license barrier that has prevented many organizations from accessing critical Austrian insolvency data. For compliance teams, credit risk analysts, and due diligence professionals, this tool provides an affordable, scalable solution for monitoring Austrian corporate distress signals.

As regulatory requirements continue to evolve and the importance of early risk detection grows, having programmatic access to insolvency data becomes increasingly valuable. This solution bridges the gap between the need for comprehensive compliance monitoring and the practical barriers that have traditionally existed.

Ready to get started with Austrian insolvency monitoring? Deploy the Ediktsdatei scraper on Apify and begin monitoring critical compliance signals today.

Additional Resources

What are your thoughts on insolvency monitoring tools? Have you faced challenges with accessing Austrian court data? Share your experiences in the comments below!

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

Peter — Fri, 17 Apr 2026 15:25:54 +0000

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

The Sixth EU Anti-Money Laundering Directive (6AMLD) comes into full effect on July 10, 2027, and compliance teams across Europe are scrambling to prepare. With stricter beneficial ownership verification requirements and increased penalties for non-compliance, manual registry searches are no longer sustainable.

The Challenge: Cross-Border Beneficial Owner Verification

Under 6AMLD, financial institutions and designated businesses must:

Verify beneficial ownership information for all corporate entities
Monitor for changes in ownership structures
Report suspicious activity within strict deadlines
Maintain auditable trails of all verification processes

The problem? Beneficial owner data is scattered across 27+ national registries with:

Different formats (XML, JSON, PDF, web pages)
Varying access methods (paid APIs, free portals, web scraping)
Update frequencies (daily, weekly, quarterly)
Search capabilities (limited to basic name/company searches)

The Solution: Automated Beneficial Owner Intelligence

Our European Business Data Suite provides programmatic access to key beneficial owner registries across four countries:

Poland: CRBR Beneficial Owners Scraper

What it does: Extracts real beneficial owner data from Poland's Central Register of Beneficial Owners
Price: $0.03 per result
Use case: Verify Polish company ownership structures, monitor for changes
Why it matters: Poland's CRBR is mandatory under 6AMLD with real-time updates

Spain: Company Directory Scraper

What it does: Accesses Spanish company registry data including beneficial owners
Price: $0.005 per result
Use case: Cross-reference Spanish entities with ownership information
Why it matters: Spain's strict transparency laws align with 6AMLD requirements

Austria: WKO Business Directory

What it does: Provides Austrian company data including ownership structures
Price: $0.003 per result
Use case: Verify Austrian beneficial ownership for due diligence
Why it matters: Austrian transparency requirements complement 6AMLD

France: Societe.com Company Data

What it does: Extracts French company director and ownership information
Price: $0.005 per result
Use case: Monitor French corporate ownership changes
Why it matters: France's expanded beneficial ownership registries fall under 6AMLD

Automated Compliance Workflows

1. New Customer Onboarding

Customer provides company ID → Cross-check all 4 country registries → 
Flag high-risk jurisdictions → Verify beneficial owners → 
Generate compliance report

2. Ongoing Monitoring

Daily scans of registries → Detect ownership structure changes →
Trigger review workflows → Update compliance profiles →
Maintain audit trail

3. Risk Assessment

Extract ownership networks → Identify politically exposed persons →
Cross-reference sanctions lists → Calculate risk scores →
Prioritize high-risk cases

Why Automation Beats Manual Searches

Method	Speed	Accuracy	Cost	Scalability	Audit Trail
Manual searches	Hours per company	60-80%	$50-100/company	Limited	Poor
Spreadsheets	Days/weeks	70-85%	$20-50/company	Limited	Medium
Our automation	Minutes	95%+	$0.01-0.03/company	Unlimited	Excellent

Getting Started with 6AMLD Compliance

Step 1: Assess Your Exposure

Map your customer base by country
Identify high-risk jurisdictions
Calculate manual compliance costs

Step 2: Test Automation

Start with pilot customers
Compare accuracy vs manual methods
Build compliance templates

Step 3: Scale Deployment

Integrate with existing workflows
Set up automated monitoring
Establish alert thresholds

Step 4: Maintain Compliance

Regular audits of automated processes
Updates for regulatory changes
Continuous improvement

The Cost of Non-Compliance

6AMLD penalties can reach up to 5% of global annual turnover or €10 million, whichever is higher. With 27+ countries implementing the directive, the compliance burden is unprecedented.

Our suite reduces compliance costs by 80-90% while improving accuracy and auditability.

Start Your 6AMLD Journey Today

The July 2027 deadline will be here before you know it. Early adopters are already building automated compliance systems, while laggards face impossible manual workloads.

Ready to automate your beneficial owner verification?

Explore our European Business Data Suite:

Automated compliance isn't just about meeting deadlines—it's about transforming compliance from a cost center to a competitive advantage.

This article is part of our European Business Data series. Stay tuned for more insights on cross-border compliance automation.

UCP and ACP Need a Third Layer: Trust Rails

Peter — Thu, 16 Apr 2026 05:59:36 +0000

If you only watched protocol updates in agentic commerce, this week might have looked like more of the same.

But if you looked at where new announcements actually landed, the signal was different:

UCP and ACP keep defining reach (where an agent can discover and attempt checkout).
A new trust layer is becoming explicit (who carries risk when an autonomous purchase goes wrong).

That second point is the story.

In the last 7 days, the market did not just talk about agent checkout mechanics. It moved toward issuer-side controls, intent proof, and liability handling as first-class infrastructure.

For merchants, this changes the implementation question from:

"Which protocol should we support first?"

to:

"How do we ship protocol coverage and trust controls together so autonomous checkout can scale without blowing up disputes?"

The 7-Day Signal (Apr 10-Apr 16)

Here are the highest-signal changes and discussions from the current window:

Apr 14, 2026: American Express launched ACE developer tooling and registered-agent purchase protection
- Official newsroom announcement: American Express introduced Agentic Commerce Experiences (ACE) and protection mechanics for registered agent purchases.
- Practical meaning: payment-side participants are now publishing explicit models for intent validation, registration, and post-transaction accountability.
Apr 14, 2026: Commerce media coverage emphasized trust, control, and visibility for agent-initiated transactions
- Industry writeups broke out the operational pieces: agent registration, account enablement, purchase intent, tokenized credential pass-through, and optional cart context.
- Practical meaning: trust is no longer an abstract "future standards" topic. It is entering implementation checklists.
Apr 10-Apr 16, 2026: Operator conversation accelerated around protocol fragmentation and execution gaps
- Builders and commerce operators repeatedly framed the same reality: one protocol path rarely covers every agent ecosystem.
- Practical meaning: merchants need a multi-surface strategy (discovery + checkout + payment trust) instead of single-protocol optimism.

UCP and ACP Are Reach Layers, Not Full Safety Models

Let's separate what each layer does.

Layer 1: Reach and Interoperability

UCP (Google/Shopify ecosystem) helps agents discover merchant capabilities and run structured commerce flows.
ACP (OpenAI/Stripe ecosystem) enables structured agent checkout interactions in the ChatGPT-linked path.

Both are essential. Neither is sufficient on its own for production-scale autonomous buying.

Why?

Because successful autonomous commerce needs answers to risk questions that protocol alone does not fully answer:

What evidence proves user intent at authorization time?
Who is accountable if the agent buys the wrong item?
How does dispute resolution separate merchant error from agent error from user error?
What data can be safely retained for adjudication without creating privacy debt?

When volume is low, teams hand-wave these questions.
When agent volume rises, they become blocking architecture.

Why This Week Matters More Than Another Spec Diff

The common pattern in early UCP/ACP discussions was:

"Get discoverable and check-out capable first."

That guidance was directionally right, but incomplete.

This week showed the next constraint very clearly:

Agentic commerce throughput is constrained by the weaker layer:

Throughput ≈ min(protocol reach, trust-rail maturity)

If trust rails lag, throughput stalls. Not because agents cannot click "buy," but because finance, risk, and support teams will cap exposure.

In plain terms:

You can win technical demos with protocol support.
You win real GMV only when risk teams sign off on intent and liability paths.

The New Merchant Architecture (Practical Version)

You do not need to boil the ocean this quarter. You do need to avoid shipping protocol support in isolation.

Use this architecture split:

A) Discovery and Capability Layer

Maintain a valid UCP profile (/.well-known/ucp) where relevant.
Keep capability declarations synchronized with real endpoint behavior.
Validate profile and endpoint health continuously (not manually before launch days).

B) Transaction Execution Layer

Implement clean, deterministic checkout state handling.
Preserve idempotency across agent retries.
Log machine-readable failure reasons so agents can recover.

C) Trust and Liability Layer

Record explicit intent artifacts for agent-initiated actions.
Capture agent identity/registration context where available.
Define dispute routing playbooks: agent error vs merchant error vs user error.
Align payment credential handling with tokenized, scoped, revocable controls.

Most teams currently invest heavily in A and B, then improvise C.
This week's market signal suggests that C is now where winners and false starts will diverge.

A 30-Day Implementation Plan You Can Actually Execute

If your team is small, here is a realistic sequencing model.

Week 1: Baseline Reach Integrity

Validate UCP profile shape and endpoint availability.
Confirm declared capabilities match production behavior.
Patch obvious hygiene gaps (HTTPS, schema paths, key metadata).

Week 2: Checkout Determinism

Add idempotency guards on create/update/complete flows.
Normalize error codes for agent-readable recovery.
Add end-to-end replay tests for interrupted flows.

Week 3: Trust Artifacts

Define and store minimal intent evidence bundle.
Capture agent/session identifiers in transaction metadata.
Document what support can and cannot adjudicate with current logs.

Week 4: Liability Readiness Review

Run simulated dispute scenarios:
- wrong color/variant selected by agent
- stale availability race
- canceled intent arriving after delayed authorization
Confirm owner and fallback path for each failure mode.
Update customer-facing policy language for autonomous purchases.

This is not "perfect security architecture."
It is enough to move from experimental to operational.

The Cost of Ignoring the Trust Layer

If you skip this shift and treat agentic commerce as protocol-only, you will usually see one of four outcomes:

High discovery, low completion: agents can find you but fail late in checkout.
Completion spikes, dispute spikes: operations spend explodes and leadership throttles rollout.
Silent risk caps: internal teams reduce allowed agent use-cases without product visibility.
Channel fragmentation debt: each ecosystem gets separate one-off fixes, no shared risk model.

In other words, engineering may report "integration complete" while finance reports "do not scale this yet."

Where UCPtools Fits (and Where It Doesn't)

UCPtools helps with the readiness and validation side:

profile and capability validation
endpoint and schema checks
implementation diagnostics you can run before shipping

It does not replace your policy, underwriting, or issuer agreements.

But it does reduce one expensive failure class: shipping broken protocol posture and discovering it only after agents already route traffic.

If you want a quick baseline, run your domain through the validator:

https://ucptools.dev/validator?utm_source=devto&utm_medium=article&utm_campaign=ai_commerce_for_developers&utm_content=risk_layer

Then use the score as your Week 1 input for the 30-day plan above.

What to Do This Week

If you are deciding where to spend engineering time in April, here is the short answer:

Do not pick between UCP and ACP as an ideology war.
- Pick based on your near-term customer channel mix.
Do not treat protocol support as the finish line.
- Add intent and liability handling to the same roadmap.
Do not wait for perfect standards convergence.
- Build a clear internal trust model now, then adapt.

The teams that move fastest from pilot to durable volume will likely be the ones that connect these layers earliest:

Reach (UCP/ACP) + Execution (checkout reliability) + Trust (intent/liability rails).

That was not obvious to most teams a month ago.
After this week, it should be.

UCP is an open standard driven by Google and Shopify. ACP is an open standard driven by OpenAI and Stripe. UCPtools is an independent community tool and is not affiliated with Google, Shopify, OpenAI, or Stripe.

BORME Corporate Acts as Structured Data: Comparing Your Options in 2026

Peter — Wed, 15 Apr 2026 10:07:13 +0000

Every business day, Spain's Boletin Oficial del Registro Mercantil (BORME) publishes hundreds of corporate acts: company incorporations, officer appointments and dismissals, capital changes, dissolutions, mergers, and insolvency proceedings. For compliance teams monitoring Spanish counterparties or B2B sales teams prospecting new incorporations, this data is essential.

The problem: BORME publishes as PDFs. The official BOE API gives you PDF URLs but not the parsed content inside them.

This article compares three options for getting structured BORME data, with code examples.

Option 1: LibreBOR (formerly LibreBORME)

URL: librebor.me
Model: Free web interface, limited API behind Cloudflare
Status: Active — last confirmed updates February/March 2026

LibreBOR is the spiritual successor to the original LibreBORME open-source project. It provides a searchable web interface for BORME data at librebor.me, where you can look up any company and see its historical BORME acts. It's free and well-structured.

However, it comes with practical limitations:

Rate limiting and Cloudflare protection make bulk programmatic access unreliable
No official API documentation — the original LibreBORME had a documented API, but LibreBOR's API access is restricted
Dependency on a single maintainer — the original LibreBORME went offline in April 2025; while LibreBOR has been stable, there's no service-level guarantee
No Apify integration — you can't schedule runs, set up webhooks, or pipe results into your existing data pipeline on Apify

LibreBOR is excellent for ad-hoc lookups. If you need to check one company's BORME history, use it. If you need to process 500 acts daily in a production pipeline, the rate limiting becomes a blocker.

Option 2: BORME Scraper Pro (spain-data-solutions on Apify)

URL: apify.com/spain-data-solutions/borme-scraper-pro
Model: $8/month platform fee + usage charges
Status: Active — 8 total users, 2 monthly active

BORME Scraper Pro is a competing Apify actor that also parses BORME PDFs. It includes proxy rotation, province filtering, and claims 99.9% success rate. The developer renamed from startquicklabs and has been actively maintaining it.

Pricing structure: a fixed $8/month platform fee plus per-usage charges. This makes economic sense if you're running daily BORME extractions at scale. For occasional use — say, pulling one week's BORME data for a due diligence project — the monthly commitment may not justify the cost.

Option 3: BORME Corporate Acts Parser (minute_contest on Apify)

URL: apify.com/minute_contest/borme-corporate-acts-scraper
Model: Pay-per-use — $0.003 per result, no monthly fee
Status: Active — free tier friendly, HTTP-only (no Puppeteer)

Our BORME actor takes a different approach: pure HTTP requests and PDF parsing with pdfjs-dist. No browser automation, no proxy required, no monthly fee. You pay $0.003 per corporate act extracted.

How it works:

Fetches the BORME Section A index from boe.es for your specified date
Downloads the PDF files listed in the index
Parses each PDF to extract structured corporate acts
Returns JSON with act type, company name, NIF, province, and full details

Input example:

{
  "date": "2026-04-15",
  "province": "Barcelona"
}

Output example:

{
  "date": "2026-04-15",
  "province": "Barcelona",
  "bormeNumber": "89",
  "actType": "Nombramientos",
  "company": "EJEMPLO SOLUCIONES SL",
  "nif": "B12345678",
  "details": {
    "appointee": "Garcia Lopez, Maria",
    "role": "Administrador único"
  }
}

Running it via API:

curl -X POST "https://api.apify.com/v2/acts/minute_contest~borme-corporate-acts-scraper/runs?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"date": "2026-04-15"}'

Running it with the Python client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")

run = client.actor("minute_contest/borme-corporate-acts-scraper").call(
    run_input={"date": "2026-04-15", "province": "Madrid"}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"{item['actType']}: {item['company']} ({item['nif']})")

Cost comparison for common use cases:

Use Case	Acts/Run	BORME Scraper Pro	Our BORME Parser
Daily monitoring (1 province, 1 month)	~1,500	$8 + usage	~$4.50
One-off due diligence (1 day, all provinces)	~500	$8 + usage	~$1.50
Quarterly batch (3 months, 2 provinces)	~9,000	$8 + usage	~$27.00

For the one-off and low-frequency use cases that most compliance teams and law firms run, pay-per-use is significantly cheaper. The break-even with BORME Scraper Pro's $8 monthly fee is around 2,600 acts per month — below that, pay-per-use wins.

What BORME Data Looks Like

BORME Section A publishes the following act types daily:

Constituciones — new company incorporations (the goldmine for B2B prospecting)
Nombramientos — officer appointments (directors, administrators, secretaries)
Ceses/Dimisiones — officer dismissals and resignations
Modificaciones — company statute changes
Aumentos de capital / Reducciones de capital — capital increases and reductions
Disoluciones — company dissolutions
Fusiones / Escisiones — mergers and spin-offs
Declaraciones de unicidad — single-member company declarations
Revocaciones de poderes — revocations of powers of attorney
Situaciones concursales — insolvency proceedings

Each act type is extracted with its specific fields. For example, a "Constitución" includes company name, NIF, registered address, initial capital, and appointed officers. A "Cese" includes the departing officer's name and role.

Practical Workflow: Monitoring New Spanish Incorporations

A common use case: your B2B sales team wants daily alerts when new companies are incorporated in your target provinces.

from apify_client import ApifyClient
import json

client = ApifyClient("YOUR_TOKEN")

# Run BORME parser for today
run = client.actor("minute_contest/borme-corporate-acts-scraper").call(
    run_input={"date": "2026-04-15"}
)

# Filter for new incorporations only
new_companies = [
    item for item in client.dataset(run["defaultDatasetId"]).iterate_items()
    if item["actType"] == "Constituciones"
]

for company in new_companies:
    print(f"NEW: {company['company']} (NIF: {company['nif']})")
    # Push to your CRM, Slack, or email pipeline

Set this up as a scheduled run on Apify (daily at 10:00 CET, after BORME publishes), add a webhook to push results to your Slack or CRM, and you have a fully automated new-business monitoring system.

Summary

	LibreBOR	BORME Scraper Pro	Our BORME Parser
Cost	Free	$8/month + usage	$0.003/act, no monthly fee
Bulk access	Rate limited	Yes (proxy rotation)	Yes (HTTP-only)
Apify integration	No	Yes	Yes
Free tier	N/A	No ($8 minimum)	Yes
Proxy required	N/A	Yes (included)	No
Maintenance risk	Single maintainer	Developer-supported	Developer-supported
Best for	Ad-hoc lookups	Daily high-volume pipelines	Occasional/batch processing

Choose based on your volume and frequency. LibreBOR for quick manual lookups. BORME Scraper Pro if you're running thousands of acts daily and can justify the monthly commitment. Our parser for everything in between — project-based due diligence, periodic compliance checks, and batch processing without a recurring fee.

European Business Data Suite: 14 Actors, 4 Countries, One Platform

Peter — Wed, 15 Apr 2026 10:07:10 +0000

Government registries across Europe share one thing in common: they have no public API. Whether you need Polish company financials from KRS, Spanish corporate acts from BORME, Austrian insolvency data from Ediktsdatei, or French director networks from Societe.com — you're stuck with manual portal searches. One query at a time.

This article maps out 14 Apify actors that give you programmatic access to government and semi-official business data sources across 4 European countries. Every actor returns structured JSON. Every actor is pay-per-use with no subscription.

The Problem: Government Portals Without APIs

European business registries were built for citizens, not developers. Here's what that means in practice:

Poland's eKRS portal requires navigating through forms, solving captchas, and downloading individual PDF/XML files for each company's financial statements
Spain's BORME publishes 500+ corporate acts daily as PDFs — the official API gives you PDF URLs but not the parsed content
Austria's Ediktsdatei insolvency register requires an IWG license from the Ministry of Justice for API access — a bureaucratic process most companies can't justify
France's Societe.com aggregates INSEE, INPI, and BODACC data with director networks and financials, but has no API — you'd need to query 3 separate government APIs and join the data yourself
Poland's CRBR beneficial owner register has no bulk API — you verify one NIP at a time
Poland's EKW land registry uses an encrypted API endpoint and captcha, making it one of the hardest registries to automate in Europe

For a compliance officer running due diligence on 200 counterparties across multiple countries, this means days of manual work. For a developer building a KYC pipeline, it means writing fragile scrapers that break when portals change.

The Suite: 14 Actors, 4 Countries

All actors run on Apify's serverless platform. You get an API endpoint, scheduled runs, webhooks, and structured JSON output. No infrastructure to manage.

Poland (9 Actors)

Actor	Registry	Price/Result	Key Use Case
KRS Financial Statements	eKRS (ekrs.ms.gov.pl)	$0.025	Balance sheets, income statements from official filings
EKW Land Registry	EKW (ekw.ms.gov.pl)	$0.04	Property ownership, mortgages, easements across 352 courts
CRBR Beneficial Owners	CRBR (crbr.podatki.gov.pl)	$0.03	UBO verification — names, citizenship, ownership %
KRZ Debtor Registry	KRZ (krz.ms.gov.pl)	$0.025	Bankruptcy and debt screening — 9 search modes
UOKiK Abusive Clauses	UOKiK register	$0.003	Contract compliance against 7,500+ banned clauses
MSiG Court Gazette	MSiG (ems.ms.gov.pl)	$0.005	20+ years of bankruptcy, liquidation, merger announcements
KNF Financial Registry	KNF (3 registries)	$0.006	Licensed financial institution verification — 75,000+ entities
BDO Waste Registry	BDO (bdo.mos.gov.pl)	$0.005	Waste contractor verification for ESG/CSRD compliance
KRS Board Members	KRS PDF extracts	$0.035	Full board member names — the official API censors them

Technical note on KRS Board Members: The official KRS1 API returns person names as "L******" (censored). This actor downloads the public PDF extract from the government portal, which contains full names. It's the only way to get non-anonymized Polish company director data programmatically.

Spain (2 Actors)

Actor	Source	Price/Result	Key Use Case
BORME Corporate Acts	BORME via boe.es	$0.003	Daily corporate acts — incorporations, appointments, capital changes
Spain Company Directory	OpenData Registradores	$0.005	Company profiles with NIF, officers, CNAE codes

BORME parses the official PDFs published daily by Spain's Registro Mercantil. It extracts structured data from 500+ daily corporate acts: new company incorporations, officer appointments and dismissals, capital increases and reductions, dissolutions and mergers.

Spain Company Directory scrapes the official Colegio de Registradores open data portal (opendata.registradores.org), which launched in 2024 but has no public API. It returns NIF, legal form, registered officers, CNAE industry codes, address, and status. Requires residential proxy.

Austria (2 Actors)

Actor	Source	Price/Result	Key Use Case
Ediktsdatei Insolvency	edikte.justiz.gv.at	$0.005	Bankruptcies, reorganizations, debt settlements
WKO Business Directory	firmen.wko.at	$0.003	620,000+ businesses with phone, email, website

Ediktsdatei is the only Apify actor providing Austrian insolvency data without requiring the IWG government license. The official API at justizonline.gv.at requires "ID Austria" authentication and bureaucratic approval — this actor scrapes the public HTML pages instead.

WKO Firmen A-Z is the Austrian Chamber of Commerce's official business directory. No API exists. This actor extracts company name, address, phone, email, website, and industry classification from 620,000+ registered businesses. Useful for B2B lead generation, market entry research, and supplier discovery.

France (1 Actor)

Actor	Source	Price/Result	Key Use Case
Societe.com Company Data	Societe.com	$0.005	Directors, financials, shareholders in one profile

Societe.com aggregates data from INSEE (SIREN/SIRET), INPI (RNE), and BODACC into combined company profiles. While individual government APIs exist (API Sirene, INPI RNE), none provide the combined director-financial-shareholder profile. This actor gives you directors with roles, simplified financials (revenue, net result), shareholders, subsidiaries, NAF code, and legal form — all in a single API call. Requires residential proxy.

Cross-Border Due Diligence Workflow

Here's a concrete example: your compliance team needs to screen a counterparty that operates across Poland, Spain, and Austria.

Step 1: Poland KRS Financial Statements
  → Pull their latest balance sheet and income statement

Step 2: Poland CRBR Beneficial Owners  
  → Identify all beneficial owners with ownership percentages

Step 3: Poland KRZ Debtor Registry
  → Check for bankruptcy proceedings or outstanding debts

Step 4: Spain BORME Corporate Acts
  → Check for recent officer changes or capital restructuring at their Spanish subsidiary

Step 5: Austria Ediktsdatei Insolvency
  → Screen for insolvency proceedings at their Austrian branch

Step 6: Cross-reference
  → Join the data to build a complete risk profile

Running this manually across 5 different portals with different interfaces, languages, and search capabilities would take hours per counterparty. With the actors above, you can automate the entire pipeline.

Quick Start Example

Here's how to call any actor via the Apify API:

# Example: Run BORME scraper for a specific date
curl -X POST "https://api.apify.com/v2/acts/minute_contest~borme-corporate-acts-scraper/runs?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "2026-04-15",
    "province": "Madrid"
  }'

Or use the Apify Python client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Run KRS Financial Statements scraper
run = client.actor("minute_contest/poland-krs-financial-scraper").call(
    run_input={"companyIds": ["0000012345"]}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"Company: {item['companyName']}")
    print(f"Total assets: {item['financialData']['totalAssets']}")
    print(f"Revenue: {item['financialData']['revenue']}")

Pricing: Pay-Per-Use vs Subscriptions

Traditional European business data providers (MGBI, Bisnode/D&B, Axesor) operate on subscription models — typically hundreds or thousands of euros per month. That makes sense if you're running thousands of queries daily. But for most compliance teams, law firms, and due diligence analysts, usage is sporadic: batch checks before a deal, periodic counterparty reviews, one-off investigations.

Pay-per-use pricing means you pay only for what you need:

A single KRS financial statement costs $0.025
A BORME day's corporate acts cost $0.003 per act
A WKO business lookup costs $0.003

Running 100 KRS financial checks costs $2.50. Running 1,000 BORME act extractions costs $3.00. No monthly commitment, no minimums.

Apify's tiered pricing also reduces the per-result cost at higher volumes (GOLD and above), so production pipelines get cheaper as you scale.

Technical Notes

Free-tier friendly actors (no proxy needed, run on Apify free plan):

KRS Financial Statements
CRBR Beneficial Owners
KRZ Debtor Registry
UOKiK Abusive Clauses
MSiG Court Gazette
KNF Financial Registry
BORME Corporate Acts
Ediktsdatei Insolvency
WKO Business Directory (free tier needs higher memory setting)

Requires residential proxy (paid Apify plan):

EKW Land Registry (encrypted API + captcha)
Spain Company Directory (F5/Volterra WAF)
Societe.com Company Data (anti-bot protection)
BDO Waste Registry (React SPA with stealth detection)
KRS Board Members (PDF download requires proxy rotation)

Which Actors Should You Start With?

For compliance/KYC teams: CRBR Beneficial Owners + KRZ Debtor Registry + KRS Financial Statements. These three cover the core Polish due diligence workflow: who owns it, are they in debt, and are they financially stable.

For B2B sales teams: WKO Business Directory (620K Austrian contacts) + BORME Corporate Acts (daily Spanish new incorporations) + KRS Board Members (Polish company directors with full names).

For credit risk analysts: Ediktsdatei Insolvency (Austrian bankruptcies) + KRZ Debtor Registry (Polish debtors) + KRS Financial Statements (Polish financials).

For M&A and competitive intelligence: Societe.com (French director networks) + BORME Corporate Acts (Spanish corporate changes) + KRS Financial Statements (Polish financials).

Bottom Line

These 14 actors exist because European government registries systematically lack public APIs. If you need programmatic access to business data from Poland, Spain, Austria, or France, and you don't want to build and maintain fragile scrapers yourself, this suite covers the most commonly needed sources.

Every actor links to its Apify page with full documentation, input schemas, and example outputs. Try any of them with the Apify free tier — most actors work without a paid plan.

UCP vs ACP Payment Architecture: Why Both Protocols Matter for AI Commerce

Peter — Wed, 15 Apr 2026 09:00:42 +0000

UCP vs ACP Payment Architecture: Why Both Protocols Matter for AI Commerce

In the realm of AI-driven commerce, two protocols have emerged as frontrunners in enabling seamless transactions between consumers and merchants: the Universal Commerce Protocol (UCP) and the Agentic Commerce Protocol (ACP). Both protocols aim to bridge the gap between AI agents and commerce platforms, yet their approaches diverge in several key ways. This article will delve into these differences, highlighting when and why you might choose one over the other.

Understanding UCP and ACP

Universal Commerce Protocol (UCP):

Developed with a focus on interconnectivity and standardized interactions.
Establishes a "trust triangle" involving consumers, merchants, and AI agents.
Leverages a decentralized manifest system for merchant discovery, ensuring flexible integration.

Agentic Commerce Protocol (ACP):

Prioritizes rapid deployment and ease of use.
Utilizes a delegated payment model, allowing agents to act as intermediaries.
Supports both centralized and decentralized discovery mechanisms.

Payment Credential Flow Differences

UCP: Centers around direct credential exchanges with robust verification steps, ensuring high security.
ACP: Employs a streamlined delegated approach, where agents facilitate transactions without directly handling sensitive credentials.

Trust Triangle vs Delegated Payment

UCP Trust Triangle: Creates a robust ecosystem where merchants and consumers can interact through verified AI agents. This approach emphasizes security and reliability.
ACP Delegated Payment: Facilitates quicker transactions by reducing the steps needed for verification, making it ideal for environments where speed is more critical than comprehensive checks.

When to Use Which Protocol?

UCP: Best suited for environments where security and interoperability are paramount. It's the protocol of choice for platforms needing a robust verification system.
ACP: Optimal for scenarios requiring rapid transaction speeds and minimal friction in onboarding new merchants or consumers.

Agorio: Dual-Protocol Support

Agorio stands out by offering dual-protocol support, seamlessly integrating both UCP and ACP to provide flexible options for developers. Whether building for security-focused platforms or speed-intensive environments, Agorio's SDK ensures compatibility and enhances the AI-commerce interface.

Conclusion

In the evolving landscape of AI commerce, the choice between UCP and ACP largely depends on specific business needs. While UCP offers rigorous security and interoperability, ACP provides speed and ease of use. By understanding and leveraging the strengths of both protocols, developers can create more effective and versatile AI-driven commerce solutions.

UOKiK Scraper: Polish Banned Contract Clauses

Peter — Tue, 14 Apr 2026 13:53:55 +0000

TL;DR

UOKiK (Urzad Ochrony Konkurencji i Konsumentow) maintains a registry of 7,500+ contract clauses that Polish courts have ruled abusive
If your business uses standard contracts in Poland, you should check this registry - using a banned clause can lead to fines and lawsuits
No API exists for the registry
I built an Apify actor that searches the registry and returns structured JSON for $0.008 per clause

Why the UOKiK Abusive Clauses Registry Matters

Poland's consumer protection framework is built on a simple but powerful rule: contract clauses that the Court of Competition and Consumer Protection (SOKiK) has declared abusive are void - automatically, regardless of whether the consumer signed the agreement. The legal basis is the Act on Competition and Consumer Protection (ustawa o ochronie konkurencji i konsumentow), which gives UOKiK enforcement authority over contract fairness across all industries.

SOKiK rulings are published in the Register of Prohibited Contractual Clauses (Rejestr Klauzul Niedozwolonych). Once a clause appears in this registry, any business using substantially identical language in their standard terms risks enforcement action from UOKiK, class-action lawsuits from consumer advocacy organizations, and individual court challenges from customers.

The registry now contains over 7,500 clauses accumulated across nearly two decades of court decisions. Industries with the highest clause counts include banking, insurance, telecommunications, e-commerce, and real estate - essentially any sector that relies on standard-form contracts.

Why UOKiK Registry Has No API

The UOKiK registry at rejestr.uokik.gov.pl is a legacy government portal. It offers a basic keyword search form with paginated results, but there are no REST endpoints, no bulk export, and no structured data format. Each clause page must be loaded individually to get the full ruling text, defendant name, industry classification, and SOKiK case number.

For law firms reviewing contract language, e-commerce companies updating terms of service, or compliance teams running periodic audits - manual search is impractical when you need to check dozens of clauses or monitor the registry for new rulings in your industry.

UOKiK Clause Data: What You Get

The scraper returns structured JSON for each clause with the following fields:

number - registry entry number
text - the full text of the banned clause
defendant - the company that was ruled against
industry - business sector classification
caseNumber - SOKiK court case reference
entryDate - when the clause was added to the registry

You can search by defendant name, by industry, or by keyword within the clause text. The actor handles pagination automatically and returns all matching results up to your configured limit.

How to Use the UOKiK Abusive Clauses Scraper

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Search by defendant company name
run = client.actor("minute_contest/uokik-clauses-scraper").call(
    run_input={
        "defendant": "mBank",
        "maxResults": 50
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for clause in items:
    print(f"Clause #{clause.get('number')}: {clause.get('text')[:100]}...")
    print(f"  Defendant: {clause.get('defendant')}")
    print(f"  Industry: {clause.get('industry')}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/uokik-clauses-scraper').call({
    defendant: 'mBank',
    maxResults: 50
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const clause of items) {
    console.log(`#${clause.number}: ${clause.text?.substring(0, 100)}...`);
    console.log(`  Industry: ${clause.industry}`);
}

Real-World Use Case: E-Commerce Terms of Service Audit

A mid-sized Polish e-commerce company is launching a new return policy. Their legal team needs to verify that none of the proposed clauses match entries in the UOKiK registry - particularly clauses about limiting liability for delivery delays, restricting refund windows, and imposing penalty fees for returns.

Using the scraper, they search for clauses in the "handel elektroniczny" (e-commerce) industry classification. The actor returns 200+ banned clauses from the sector. The legal team cross-references their draft policy against the results, identifies two clauses that are substantially similar to banned entries, and rewrites them before launch. Without automated access, this review would have taken a full day of manual searching. With the scraper, it takes under 10 minutes.

Who Needs the UOKiK Scraper

Law firms - check proposed contract language against banned clauses before signing
E-commerce companies - ensure terms of service and return policies don't contain abusive clauses
Insurance companies - review policy terms against historical rulings
Banks and fintech - validate loan agreements and fee schedules
Compliance teams - periodic audit of standard contracts against the full registry
Consumer rights organizations - research and advocacy using structured data

Pricing

Method	Cost
Manual search on UOKiK website	Free (slow, no export)
This actor	~$3 per 1,000 clauses

Free $5 Apify credits on signup = ~1,500 clause lookups at no cost.

FAQ

Can I search the UOKiK registry by industry sector?

Yes. The actor supports filtering by industry classification. This is useful for compliance teams that want to audit all banned clauses relevant to their specific sector - for example, retrieving all clauses from banking, insurance, or e-commerce.

Are UOKiK banned clauses legally binding for all companies?

Yes. Once SOKiK rules a clause abusive and it enters the registry, using substantially identical language in any standard-form contract is prohibited across the entire market - not just for the defendant company. UOKiK can impose fines of up to 10% of annual revenue for violations.

How often is the UOKiK registry updated?

The registry is updated as new SOKiK rulings are issued. New clauses are added regularly, which is why periodic monitoring is important for compliance teams. The scraper lets you automate this by running scheduled searches for new entries.

Try it: apify.com/minute_contest/uokik-clauses-scraper

This is part of the Polish Business Data APIs series covering programmatic access to Polish government registries.

MSiG Scraper: Monitor Sądowy od 2001 Roku

Peter — Tue, 14 Apr 2026 13:45:18 +0000

TL;DR

MSiG (Monitor Sądowy i Gospodarczy) to oficjalny dziennik sądowy publikowany codziennie od 2001 roku
Zawiera każde zgłoszenie upadłości, likwidacji, restrukturyzacji i zmianę w KRS z ponad 20 lat
Portal rządowy nie ma oficjalnego API - ale nieudokumentowany endpoint REST istnieje za frontendem jQuery DataTables
Zbudowałem aktora na Apify, który odpytuje API bezpośrednio i zwraca JSON za $0.01 za wynik

Czym jest MSiG i dlaczego ma znaczenie dla wywiadu biznesowego

MSiG - Monitor Sądowy i Gospodarczy - to polski odpowiednik dziennika sądowego. Publikowany przez Ministerstwo Sprawiedliwości od 2001 roku, jest autorytatywnym źródłem prawnym zdarzeń korporacyjnych w Polsce. Każde otwarcie postępowania upadłościowego, zatwierdzenie planu restrukturyzacji, zarządzenie likwidacji, zmiana w KRS (Krajowy Rejestr Sądowy) - jest publikowane w MSiG.

To czyni MSiG jednym z najcenniejszych zbiorów danych dla każdego zajmującego się polskim wywiadem biznesowym. Archiwum obejmuje ponad dwie dekady codziennych publikacji i setki tysięcy ogłoszeń. Każda upadłość w Polsce od 2001 roku jest tutaj. Każda zmiana w zarządzie, podwyższenie kapitału, fuzja - opublikowana.

Dla każdego w ryzyku kredytowym, windykacji, usługach prawnych lub wywiadzie konkurencyjnym, monitorowanie MSiG jest niezbędne. Ale portal na wyszukiwarka-msig.ms.gov.pl jest zaprojektowany do ręcznego wyszukiwania:

Jedna firma na raz
Wyniki w paginowanym HTML
Brak eksportu
Brak dokumentacji API

Jeśli musisz monitorować setki lub tysiące firm albo analizować historyczne trendy niewypłacalności, podejście ręczne się nie skaluje.

MSiG monitor sądowy scraper: jak działa ukryte API

Portal MSiG używa jQuery DataTables z REST API pod spodem, które akceptuje parametry wyszukiwania JSON i zwraca ustrukturyzowane dane.

Dwa ciekawe szczegoly techniczne:

1. Dynamiczne rozwiazywanie URL API

Bazowy URL API nie jest zahardcodowany - jest pobierany w runtime z dedykowanego endpointu (home/getapiurl). Oznacza to, że rząd może przenieść API bez zmian we frontendzie. Scraper obsługuje to, najpierw rozwiązując aktualny URL API przed wykonaniem jakichkolwiek zapytań.

2. Literowka w produkcyjnym API

Endpoint do pełnego tekstu to /Monitor/Detalis - tak, "Detalis" zamiast "Details". Ta literówka działa w rządowym API od lat. Scraper używa błędnego URL, ponieważ to właśnie on działa.

Endpoint wyszukiwania /Monitor/Search akceptuje zakresy dat, nazwy podmiotów, numery KRS/NIP, sygnatury spraw i wyszukiwanie pełnotekstowe w treści ogłoszeń. Wyniki są zwracane jako JSON z metadanymi (daty publikacji, numery monitora, klasyfikacja rozdziałów) i opcjonalnie pełnym tekstem każdego ogłoszenia.

Pobieranie pełnego tekstu to oddzielne wywołanie API na każde ogłoszenie. Dla dużych zbiorów wyników oznacza to wiele requestów. Aktor grupuje je efektywnie i obsługuje limitowanie ze strony serwerów rządowych.

Jak używać MSiG monitor sądowy scrapera

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

run = client.actor("minute_contest/msig-scraper").call(
    run_input={
        "dateFrom": "2026-01-01",
        "dateTo": "2026-03-31",
        "searchType": "A",          # A = ogłoszenia, B = wpisy KRS
        "entityName": "Getin",
        "fetchDetails": True,        # dołącz pełny tekst ogłoszenia
        "maxResults": 100
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for entry in items:
    print(f"{entry['entityName']} | {entry.get('chapterName')}")
    print(f"  Sygnatura: {entry['signatureOfCase']}")
    print(f"  Data publikacji: {entry['dateOfPublication']}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/msig-scraper').call({
    dateFrom: '2026-01-01',
    dateTo: '2026-03-31',
    searchType: 'A',
    entityName: 'Getin',
    fetchDetails: true,
    maxResults: 100
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach(e => {
    console.log(`${e.entityName} | ${e.chapterName}`);
    console.log(`  Sygnatura: ${e.signatureOfCase}`);
});

Dane z MSiG scrapera: co dostajesz

Pole	Przykład
entityName	GETIN NOBLE BANK S.A. W UPADŁOŚCI
krs	0000019193
nip	1080000568
signatureOfCase	XVIII GUp 25/23
chapterName	Postępowania upadłościowe
monitorNumber	MSiG 48/2026
dateOfPublication	2026-03-11
numberOfNotice	12345
textInPosition	Nagłówek ogłoszenia
textInBody	Pełny tekst ogłoszenia sądowego

MSiG monitor sądowy: tryby wyszukiwania

searchType	Co obejmuje
A (Ogłoszenia)	Upadłości, restrukturyzacje, likwidacje
B (Wpisy KRS)	Nowe rejestracje, zmiany w zarządzie, podwyższenia kapitału, połączenia

Można łączyć filtry: zakres dat + nazwa podmiotu + NIP + sygnatura sprawy + wyszukiwanie pełnotekstowe.

Przykład z praktyki: monitoring portfela ryzyka kredytowego

Firma faktoringowa zarządza portfelem 2000 polskich klientów biznesowych. Co kwartał ich zespół ryzyka musi sprawdzić, czy któryś z klientów złożył wniosek o upadłość, wszedł w restrukturyzację lub miał istotne zmiany w KRS.

Bez automatyzacji analityk otwiera portal MSiG, wpisuje nazwę każdej firmy, przegląda wyniki i dokumentuje ustalenia. Przy 3-5 minutach na firmę, screening całego portfela zajmuje 100-170 godzin - około miesiąca pracy jednej osoby.

Z MSiG Monitor Sądowy scraperem ten sam zespół uruchamia zaplanowane zadanie, które odpytuje aktora numerem KRS lub NIP każdego klienta, z filtrem na ostatnie 90 dni. Wyniki trafiają bezpośrednio do systemu zarządzania ryzykiem. Każde nowe zgłoszenie upadłości lub ogłoszenie restrukturyzacji uruchamia automatyczny przegląd.

To redukuje screening portfela z tygodni do minut. Co ważniejsze, umożliwia ciągły monitoring zamiast okresowych kontroli - wychwytując problemy w ciągu dni od publikacji, a nie kwartałów.

Kto potrzebuje danych z MSiG Monitora Sądowego

Monitoring upadłości - alerty gdy firmy z Twojego portfela składają wniosek o upadłość
Windykacja - śledzenie postępowań dotyczących dłużników
Ryzyko kredytowe - screening nowych klientów pod kątem historii niewypłacalności
Badania prawne - wyszukiwanie ogłoszeń sądowych po sygnaturze sprawy
Analiza rynku - trendy niewypłacalności według sektora lub regionu z 20+ lat danych
Monitoring zmian KRS - wykrywanie zmian w zarządach, podwyższeń kapitału, fuzji

FAQ

Czy mogę szukać po numerze KRS lub NIP zamiast po nazwie firmy?

Tak. Aktor akceptuje entityName, krs, nip i signatureOfCase jako parametry wyszukiwania. Można użyć dowolnej kombinacji. Wyszukiwanie po KRS i NIP jest dokładne (exact match) i jest najbardziej niezawodnym sposobem na znalezienie ogłoszeń dla konkretnej firmy, ponieważ nazwy firm mogą się różnić między zgłoszeniami (skróty, sufiksy formy prawnej itp.).

Co robi parametr `fetchDetails`?

Gdy fetchDetails jest ustawiony na true, aktor wykonuje dodatkowe wywołanie API dla każdego wyniku, aby pobrać pełny tekst ogłoszenia sądowego (textInBody). Bez niego dostajesz tylko metadane (nazwa podmiotu, daty, rozdział, sygnatura). Włącz go, gdy potrzebujesz faktycznej treści ogłoszeń - na przykład aby wydobyć listy wierzycieli lub warunki restrukturyzacji. Wyłącz dla szybszych wyników, gdy interesuje Cię tylko to, czy ogłoszenie istnieje.

Jak daleko wstecz sięga archiwum MSiG?

Cyfrowe archiwum na wyszukiwarka-msig.ms.gov.pl sięga do 2001 roku. Scraper może odpytywać dowolny zakres dat w tym okresie. Daje to dostęp do ponad 20 lat zgłoszeń upadłości, zmian KRS i innych zdarzeń korporacyjnych - cenny zbiór danych do analizy historycznych trendów lub due diligence długo istniejących firm.

Ceny

Metoda	Koszt
Ręczne wyszukiwanie na portalu MSiG	Darmowe (po jednym, bez eksportu)
MGBI API MSiG	900-2200 zł/mies. subskrypcja
Ten aktor	~20 zł za 1000 wyników

Darmowe $5 kredytów Apify = ~900 wyników MSiG za darmo.

Wypróbuj: apify.com/minute_contest/msig-scraper

Ten artykuł jest częścią serii Polish Business Data APIs o programistycznym dostępie do polskich rejestrów publicznych.

eKRS Scraper: Sprawozdania Finansowe z KRS

Peter — Tue, 14 Apr 2026 13:41:46 +0000

TL;DR

Polskie spółki muszą składać roczne sprawozdania finansowe w KRS
Są publicznie dostępne na ekrs.ms.gov.pl - ale tylko przez ręczny interfejs webowy
Portal używa szyfrowania AES z kluczem rotowanym co godzinę (opartym na strefie czasowej Warszawa)
Zbudowałem eKRS sprawozdania finansowe scraper na Apify, który wyciąga ustrukturyzowane dane finansowe (aktywa, pasywa, przychody, zysk netto) za $0.03 za firmę

Czym jest eKRS i dlaczego dostęp do sprawozdań finansowych ma znaczenie

eKRS (Elektroniczny Krajowy Rejestr Sądowy) to elektroniczny portal Krajowego Rejestru Sądowego prowadzony przez Ministerstwo Sprawiedliwości. Od 2018 roku wszystkie polskie spółki z numerem KRS mają obowiązek składania rocznych sprawozdań finansowych elektronicznie przez ten portal. Obejmują one bilans, rachunek zysków i strat oraz informacje dodatkowe.

To tworzy jedną z największych publicznie dostępnych baz danych finansowych firm w Europie Środkowej. Setki tysięcy spółek składają sprawozdania co roku, a wszystkie są dostępne do publicznego wglądu bezpłatnie. Dane obejmują zarówno małe spółki z o.o. z minimalnym przychodem, jak i największe spółki giełdowe w Polsce.

Problem leży w dostępie. Portal ekrs.ms.gov.pl został zaprojektowany do ręcznego przeglądania po jednym dokumencie. Brak eksportu danych, brak masowego pobierania, brak publicznego API. Jeśli budujesz modele ryzyka kredytowego, analizujesz konkurencję w branży lub sprawdzasz setki celów inwestycyjnych - potrzebujesz tych danych w formacie maszynowym, a nie w rządowej aplikacji serwującej XML i XHTML po jednym dokumencie.

Jak działa szyfrowanie AES z rotacją klucza w eKRS

Portal eKRS to aplikacja Angular hostowana na infrastrukturze OpenShift Ministerstwa Sprawiedliwości. Szyfruje numery KRS przed wysłaniem zapytań API - ale z nietypowym mechanizmem.

Klucz szyfrowania zmienia się co godzinę.

Klucz pochodzi z bieżącej daty i godziny w strefie czasowej Warszawa, sformatowanej jako yyyy-MM-dd-HH i dopełnionej do 16 znaków bajtami null. Więc o 14:00 8 kwietnia 2026 w Warszawie klucz to:

2026-04-08-14\x00\x00\x00

O 15:00 klucz rotuje na:

2026-04-08-15\x00\x00\x00

Zapytania z kluczem wygenerowanym z błędną godziną nie przechodzą. Scraper obsługuje konwersję strefy czasowej używając Intl.DateTimeFormat z Europe/Warsaw - to krytyczne dla poprawnego generowania klucza, szczególnie podczas zmian czasu (Polska przechodzi między CET a CEST) i w kontenerach Docker ustawionych na UTC.

Portal implementuje również podpisywanie zapytań i zarządzanie sesją, które muszą być zreplikowane. Każde sprawozdanie finansowe jest przechowywane jako XML (Polskie Standardy Rachunkowości - PSR), XHTML/iXBRL (Międzynarodowe Standardy Sprawozdawczości Finansowej - MSSF) lub okazjonalnie jako skan PDF. Scraper obsługuje wszystkie trzy formaty i normalizuje je do ujednoliconej struktury JSON.

eKRS sprawozdania finansowe: co dostajesz

Aktor parsuje XML (Polskie Standardy Rachunkowości) i XHTML/iXBRL (MSSF) do ujednoliconego formatu JSON:

Pole	Opis
krs	Numer KRS
companyName	Pełna nazwa spółki
year	Rok sprawozdawczy
fileFormat	xml, xhtml lub pdf
financials.totalAssets	Aktywa razem
financials.fixedAssets	Aktywa trwałe
financials.currentAssets	Aktywa obrotowe
financials.cashAndEquivalents	Środki pieniężne
financials.equity	Kapitał własny
financials.longTermLiabilities	Zobowiązania długoterminowe
financials.shortTermLiabilities	Zobowiązania krótkoterminowe
financials.revenue	Przychody
financials.operatingProfit	Zysk operacyjny
financials.netProfit	Zysk netto

Aktor zwraca również surowe źródło XML/XHTML do własnego parsowania - przydatne jeśli potrzebujesz pól wykraczających poza standardowy zestaw, takich jak harmonogramy amortyzacji, rezerwy podatkowe czy raportowanie segmentowe.

Jak używać eKRS sprawozdania finansowe scraper

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Wyszukiwanie po NIP lub KRS
run = client.actor("minute_contest/poland-krs-financial-scraper").call(
    run_input={"nip": "5261040828"}  # lub krs: "0000019193"
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for stmt in items:
    fin = stmt.get("financials", {})
    print(f"{stmt['companyName']} - {stmt['year']}")
    print(f"  Przychody: {fin.get('revenue')}")
    print(f"  Zysk netto: {fin.get('netProfit')}")
    print(f"  Aktywa razem: {fin.get('totalAssets')}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/poland-krs-financial-scraper').call({
    nip: '5261040828'
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const stmt of items) {
    console.log(`${stmt.companyName} - ${stmt.year}`);
    console.log(`  Przychody: ${stmt.financials?.revenue}`);
    console.log(`  Zysk netto: ${stmt.financials?.netProfit}`);
}

Praktyczny przypadek: screening kondycji finansowej dostawców

Wyobraź sobie, że zarządzasz zakupami w firmie produkcyjnej z 200 polskimi dostawcami. CFO chce kwartalnego raportu o stabilności finansowej dostawców - czy któryś z nich jest zagrożony niewypłacalnością?

Bez tego scrapera ktoś z Twojego zespołu musiałby odwiedzić ekrs.ms.gov.pl 200 razy, ręcznie wyszukać każdą firmę, pobrać plik XHTML lub XML, a potem jakoś wyciągnąć odpowiednie dane finansowe do arkusza. To zajmuje dni ręcznej pracy i jest podatne na błędy.

Z eKRS scraperem przekazujesz 200 numerów NIP w jednej partii. W ciągu kilku minut dostajesz ustrukturyzowany JSON z aktywami, kapitałem własnym, przychodami i zyskiem netto dla każdego dostawcy. Uruchom prosty filtr: oznacz każdego dostawcę, gdzie kapitał własny jest ujemny, gdzie wskaźnik długu do aktywów przekracza 80% lub gdzie przychody spadły o ponad 30% rok do roku. Masz system wczesnego ostrzegania o ryzyku dostawców - zbudowany w jedno popołudnie za około 25 zł.

Kto potrzebuje danych ze sprawozdań finansowych eKRS

Ryzyko kredytowe - sprawdź wypłacalność firmy przed podpisaniem umowy lub udzieleniem kredytu
Analiza konkurencji - monitoruj przychody i rentowność konkurentów w ujęciu wieloletnim
Screening inwestycyjny - hurtowa analiza kondycji finansowej celów przejęć w danym sektorze
Due diligence dostawców - zweryfikuj stabilność finansową kluczowych dostawców przed podpisaniem długoletnich kontraktów
Monitoring portfela - śledź roczne wyniki firm w portfelu inwestycyjnym

Porównanie cen eKRS Scraper

Metoda	Koszt
Ręczne pobieranie z ekrs.ms.gov.pl	Darmowe (po jednym, bez ustrukturyzowanych danych)
MGBI API sprawozdania	900-2200 zł/mies. subskrypcja
Ten aktor	~13 zł za 100 firm

Darmowe $5 kredytów Apify = ~190 sprawozdań finansowych za darmo.

FAQ

Jakie standardy sprawozdawczości obsługuje scraper?

eKRS sprawozdania finansowe scraper obsługuje zarówno Polskie Standardy Rachunkowości (PSR) składane jako XML, jak i Międzynarodowe Standardy Sprawozdawczości Finansowej (MSSF) składane jako XHTML/iXBRL. Obsługuje też skany PDF, choć ekstrakcja ustrukturyzowanych danych z PDF jest ograniczona. Aktor normalizuje wszystkie formaty do jednego schematu JSON - dostajesz te same nazwy pól niezależnie od formatu źródła.

Za ile lat wstecz są dostępne sprawozdania?

Portal eKRS zawiera sprawozdania finansowe składane od czasu wprowadzenia obowiązku elektronicznego w 2018 roku. Większość spółek ma dostępne dane za 5-7 lat. Niektóre większe spółki, które składały dobrowolnie przed nakazem, mogą mieć starsze rekordy. Scraper zwraca wszystkie dostępne lata dla danej spółki.

Czy mogę szukać po NIP zamiast numeru KRS?

Tak. W odróżnieniu od KRS scraper do danych zarządu, eKRS sprawozdania finansowe scraper akceptuje zarówno NIP (numer identyfikacji podatkowej) jak i numer KRS jako input. To wygodne, bo NIP jest często łatwiej znaleźć - widnieje na fakturach, stronach internetowych i w większości katalogów biznesowych.

Wypróbuj: apify.com/minute_contest/poland-krs-financial-scraper

Ten artykuł jest częścią serii Polish Business Data APIs o programistycznym dostępie do polskich rejestrów publicznych.

KRS Scraper: Pełne Nazwiska Zarządu z KRS

Peter — Tue, 14 Apr 2026 13:40:17 +0000

TL;DR

KRS (Krajowy Rejestr Sądowy) to oficjalny rejestr spółek, fundacji i stowarzyszeń w Polsce
Oficjalne API (api-krs.ms.gov.pl) celowo anonimizuje dane osobowe - nazwiska stają się L******
Odpis PDF z tego samego portalu rządowego zawiera pełne, niezanonimizowane dane
Zbudowałem KRS dane zarządu scraper na Apify, który replikuje szyfrowanie AES portalu i pobiera odpisy PDF - zwraca JSON z pełnymi nazwiskami zarządu za $0.04 za firmę

Czym jest KRS i dlaczego dane zarządu są kluczowe

KRS - Krajowy Rejestr Sądowy - to centralny rejestr podmiotów gospodarczych prowadzony przez Ministerstwo Sprawiedliwości. Każda polska spółka z o.o., spółka akcyjna, fundacja i stowarzyszenie musi być tu zarejestrowana. Rejestr zawiera dane ponad 800 000 podmiotów, w tym ich formę prawną, adres siedziby, kapitał zakładowy oraz - co kluczowe - nazwiska członków zarządu, rady nadzorczej i wspólników.

Dane o zarządzie to fundament prospectingu B2B, compliance i due diligence w Polsce. Jeśli oceniasz potencjalnego dostawcę, weryfikujesz kto kontroluje firmę na potrzeby KYC/AML, albo budujesz listę decydentów do cold outreach - potrzebujesz nazwisk osób, które faktycznie prowadzą te firmy. Problem polega na tym, że najwygodniejszy sposób dostępu do danych KRS - oficjalne API - celowo ukrywa właśnie te informacje.

Dlaczego API KRS anonimizuje nazwiska

Oficjalne API KRS na api-krs.ms.gov.pl zwraca dane spółek, ale z ukrytymi danymi osobowymi:

{
  "nazwa": "EXAMPLE SP. Z O.O.",
  "reprezentacja": {
    "sklad": [
      { "nazwisko": "L******", "imiona": "A***" }
    ]
  }
}

To bezużyteczne, jeśli potrzebujesz wiedzieć kto faktycznie zarządza firmą. Stanowisko rządu jest niespójne - dane osobowe w KRS są publiczne z mocy prawa, publikowane w Monitorze Sądowym i Gospodarczym. Każdy może przyjść do sądu rejonowego i zamówić odpis za kilka złotych. Ale API redaguje nazwiska, powołując się na RODO, jednocześnie udostępniając te same dane w formie PDF na tym samym portalu.

Ta niespójność tworzy praktyczną lukę - programiści budujący systemy automatyczne nie mogą uzyskać ustrukturyzowanych danych o nazwiskach przez oficjalną ścieżkę API.

Jak działa KRS dane zarządu scraper

Portal wyszukiwarka-krs.ms.gov.pl oferuje odpisy PDF zawierające pełne, niezanonimizowane dane. Zarząd, rada nadzorcza, wspólnicy - wszystko z kompletnymi nazwiskami.

Haczyk: pobranie tych PDF-ów wymaga replikacji dwóch mechanizmów bezpieczeństwa portalu.

Szyfrowanie AES-128-CBC

Numer KRS jest szyfrowany przed wysłaniem do API. Klucz szyfrowania?

TopSecretApiKey1

Tak, naprawdę. Klucz jest zahardcodowany w JavaScript frontendu Angular. IV (wektor inicjalizacji) = klucz. Każdy kto przejrzy źródło frontendu może zreplikować szyfrowanie - i dokładnie to robi scraper.

Steganografia Tokenowa

Po zaszyfrowaniu portal generuje 512-znakowy token, który ukrywa numer KRS i timestamp na określonych pozycjach tablicy:

Tworzy tablicę 512 losowych znaków alfanumerycznych
Wstawia zaszyfrowany KRS na pozycje np. [193, 8, 327, 501, 112, 74, 409, 226, 16, 306]
Wstawia sumę kontrolną na pozycje [24, 46, 174, 345]
Wykonuje circular right-shift na całej tablicy
Łączy w string i wysyła jako parametr API

Scraper replikuje cały proces generowania tokenu, a następnie parsuje pobrany PDF na ustrukturyzowane pola JSON.

KRS dane zarządu: co dostajesz

Pole	Przykład
companyName	EXAMPLE SP. Z O.O.
krsNumber	0000019193
nip	5261006099
regon	010058960
legalForm	SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ
address	ul. Przykładowa 1, 00-001 Warszawa
boardMembers	[{fullName, firstName, surname, role}]
supervisoryBoard	[{fullName, firstName, surname, role}]
shareholders	[{name, sharesValue, sharesCount}]
shareCapital	500000.00

Dostępne są dwa typy odpisów: aktualny (tylko bieżący stan) i pelny (pełna historia zmian - byli członkowie zarządu, zmiany adresu, zmiany kapitału).

Jak używać KRS Scraper

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

run = client.actor("minute_contest/krs-fullnames-scraper").call(
    run_input={
        "krsNumbers": ["0000019193", "0000366824"],
        "extractType": "aktualny"  # 'aktualny' = bieżące, 'pelny' = pełna historia
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for company in items:
    print(f"{company['companyName']} (KRS: {company['krsNumber']})")
    for member in company.get("boardMembers", []):
        print(f"  {member['role']}: {member['fullName']}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/krs-fullnames-scraper').call({
    krsNumbers: ['0000019193', '0000366824'],
    extractType: 'aktualny'
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const company of items) {
    console.log(`${company.companyName} - NIP: ${company.nip}`);
    company.boardMembers.forEach(m => console.log(`  ${m.role}: ${m.fullName}`));
}

Praktyczny przypadek: prospecting B2B na polskim rynku

Wyobraź sobie, że jesteś SDR-em w firmie SaaS celującej w polskie średnie firmy. Masz listę 500 numerów KRS z katalogu branży. Musisz znaleźć prezesa zarządu każdej firmy do spersonalizowanego outreach.

Bez tego scrapera Twoje opcje to: (1) odwiedzić wyszukiwarka-krs.ms.gov.pl 500 razy i ręcznie pobrać każdy PDF, (2) zapłacić 900-2200 zł/mies. za subskrypcję komercyjnego dostawcy danych, (3) użyć API i dostać L****** zamiast nazwisk.

Z KRS scraperem przekazujesz wszystkie 500 numerów KRS w jednym wywołaniu API. W ciągu kilku minut dostajesz JSON z pełnym nazwiskiem i rolą każdego członka zarządu. Filtruj po PREZES ZARZĄDU i masz listę do outreach - ze zweryfikowanymi NIP i REGON do porównania z innymi rejestrami.

Całkowity koszt: około 85 zł za 500 firm.

Kto potrzebuje danych o zarządzie z KRS

Sprzedaż B2B - znajdź imiona i nazwiska decydentów przed cold outreach
Compliance KYC/AML - zweryfikuj kto kontroluje firmę
Due diligence - sprawdź skład zarządu przed inwestycją
Ryzyko kredytowe - sprawdź powiązania między firmami przez wspólnych członków zarządu
Kancelarie prawne - identyfikacja stron w sporach i negocjacjach kontraktowych

Porównanie cen KRS Scraper

Dostawca	Model	Koszt za 100 firm
Oficjalne API KRS	Darmowe	0 zł (ale nazwiska ukryte)
Transparent Data	Subskrypcja	~130 zł
MGBI	Subskrypcja	900-2200 zł/mies.
Ten aktor	Pay-per-use	~17 zł

Darmowe $5 kredytów Apify = ~125 firm za darmo.

FAQ

Czy dane o zarządzie z KRS są legalnie publiczne?

Tak. KRS jest rejestrem publicznym z mocy ustawy (Ustawa o Krajowym Rejestrze Sądowym). Każdy może zamówić pełny odpis w sądzie rejonowym za niewielką opłatę. Dane są też publikowane w Monitorze Sądowym i Gospodarczym. Anonimizacja w API to decyzja polityczna rządu, nie wymóg prawny - odpisy PDF z tego samego portalu zawierają pełne nazwiska.

Czy mogę szukać firm po NIP zamiast numeru KRS?

KRS dane zarządu scraper przyjmuje numery KRS jako input. Jeśli masz tylko NIP, możesz najpierw użyć oficjalnego endpointu wyszukiwania API KRS, żeby znaleźć odpowiadający numer KRS, a następnie przekazać go do aktora. Alternatywnie, aktor eKRS do sprawozdań finansowych z tej serii przyjmuje NIP bezpośrednio.

Jak aktualne są dane?

Scraper pobiera oficjalny odpis z portalu Ministerstwa Sprawiedliwości w czasie rzeczywistym. Dane odzwierciedlają aktualny stan rejestru KRS - typowo aktualizowany w ciągu kilku dni od złożenia wniosku w sądzie. To te same dane, które dostałbyś odwiedzając portal ręcznie.

Wypróbuj: apify.com/minute_contest/krs-fullnames-scraper

Ten artykuł jest częścią serii Polish Business Data APIs o programistycznym dostępie do polskich rejestrów publicznych.

UOKiK Scraper: Klauzule Niedozwolone z API

Peter — Tue, 14 Apr 2026 13:39:15 +0000

TL;DR

UOKiK (Urząd Ochrony Konkurencji i Konsumentów) prowadzi rejestr 7 500+ klauzul umownych uznanych przez sądy za niedozwolone
Jeśli Twoja firma stosuje wzorce umów w Polsce, powinieneś sprawdzać ten rejestr - użycie zakazanej klauzuli może prowadzić do kar i procesów
Brak API do rejestru
Zbudowałem aktora na Apify, który przeszukuje rejestr i zwraca JSON za $0.008 za klauzulę

Dlaczego Rejestr Klauzul Niedozwolonych UOKiK Jest Ważny

Polski system ochrony konsumentów opiera się na prostej, ale skutecznej zasadzie: klauzule umowne uznane przez Sąd Ochrony Konkurencji i Konsumentów (SOKiK) za abuzywne są nieważne - automatycznie, niezależnie od tego czy konsument podpisał umowę. Podstawą prawną jest ustawa o ochronie konkurencji i konsumentów, która daje UOKiK uprawnienia do egzekwowania uczciwości umów we wszystkich branżach.

Orzeczenia SOKiK są publikowane w Rejestrze Klauzul Niedozwolonych. Gdy klauzula pojawi się w rejestrze, każda firma stosująca identyczne lub istotnie podobne sformułowania w swoich wzorcach umów ryzykuje postępowanie ze strony UOKiK, pozwy zbiorowe od organizacji konsumenckich oraz indywidualne zaskarżenia ze strony klientów.

Rejestr zawiera obecnie ponad 7 500 klauzul zgromadzonych przez niemal dwie dekady orzeczeń sądowych. Branże z największą liczbą zakazanych klauzul to bankowość, ubezpieczenia, telekomunikacja, e-commerce i nieruchomości - czyli wszystkie sektory opierające się na wzorcach umów.

Dlaczego Rejestr UOKiK Nie Ma API

Rejestr UOKiK na stronie rejestr.uokik.gov.pl to klasyczny portal rządowy. Oferuje podstawowy formularz wyszukiwania ze stronicowanymi wynikami, ale nie udostępnia endpointów REST, eksportu hurtowego ani ustrukturyzowanego formatu danych. Każda strona z klauzulą musi być załadowana osobno, żeby uzyskać pełny tekst orzeczenia, nazwę pozwanego, klasyfikację branżową i sygnaturę sprawy SOKiK.

Dla kancelarii prawnych sprawdzających zapisy umowne, firm e-commerce aktualizujących regulaminy czy zespołów compliance prowadzących okresowe audyty - ręczne przeszukiwanie jest niepraktyczne, gdy trzeba zweryfikować dziesiątki klauzul lub monitorować rejestr pod kątem nowych orzeczeń w swojej branży.

Dane z Rejestru UOKiK: Co Otrzymujesz

Scraper zwraca ustrukturyzowany JSON dla każdej klauzuli z następującymi polami:

number - numer wpisu w rejestrze
text - pełny tekst zakazanej klauzuli
defendant - firma, przeciwko której wydano orzeczenie
industry - klasyfikacja branżowa
caseNumber - sygnatura sprawy SOKiK
entryDate - data dodania klauzuli do rejestru

Możesz wyszukiwać po nazwie pozwanego, po branży lub po słowie kluczowym w tekście klauzuli. Aktor automatycznie obsługuje stronicowanie i zwraca wszystkie pasujące wyniki do skonfigurowanego limitu.

Jak Używać UOKiK Klauzule Niedozwolone Scraper

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Wyszukiwanie po nazwie pozwanego
run = client.actor("minute_contest/uokik-clauses-scraper").call(
    run_input={
        "defendant": "mBank",
        "maxResults": 50
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
for clause in items:
    print(f"Klauzula #{clause.get('number')}: {clause.get('text')[:100]}...")
    print(f"  Pozwany: {clause.get('defendant')}")
    print(f"  Branża: {clause.get('industry')}")

JavaScript (Node.js)

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('minute_contest/uokik-clauses-scraper').call({
    defendant: 'mBank',
    maxResults: 50
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach(c => console.log(`#${c.number}: ${c.text?.substring(0, 100)}...`));

Praktyczny Przykład: Audyt Regulaminu Sklepu Internetowego

Średniej wielkości polski sklep internetowy wprowadza nową politykę zwrotów. Zespół prawny musi zweryfikować, że żaden z proponowanych zapisów nie pokrywa się z wpisami w rejestrze UOKiK - szczególnie klauzule dotyczące ograniczenia odpowiedzialności za opóźnienia w dostawie, skracania okresu na zwrot i naliczania kar za zwroty.

Używając scrapera, wyszukują klauzule w klasyfikacji branżowej "handel elektroniczny". Aktor zwraca 200+ zakazanych klauzul z tego sektora. Zespół prawny porównuje projekt regulaminu z wynikami, identyfikuje dwa zapisy istotnie podobne do zakazanych wpisów i przepisuje je przed publikacją. Bez zautomatyzowanego dostępu ten przegląd zająłby cały dzień ręcznego wyszukiwania. Ze scraperem zajmuje mniej niż 10 minut.

Kto Potrzebuje UOKiK Scraper

Kancelarie prawne - weryfikacja proponowanych zapisów umownych przed podpisaniem
Firmy e-commerce - sprawdzenie regulaminów i polityk zwrotów pod kątem klauzul abuzywnych
Firmy ubezpieczeniowe - przegląd warunków polis w kontekście orzeczeń SOKiK
Banki i fintech - walidacja umów kredytowych i tabel opłat
Zespoły compliance - okresowy audyt wzorców umów wobec pełnego rejestru
Organizacje konsumenckie - badania i rzecznictwo z wykorzystaniem ustrukturyzowanych danych

Ceny

Metoda	Koszt
Ręczne wyszukiwanie na stronie UOKiK	Darmowe (wolne, bez eksportu)
Ten aktor	~13 zł za 1000 klauzul

Darmowe $5 kredytów Apify = ~1500 klauzul za darmo.

FAQ

Czy można przeszukiwać rejestr UOKiK po branży?

Tak. Aktor obsługuje filtrowanie po klasyfikacji branżowej. Jest to przydatne dla zespołów compliance, które chcą przeprowadzić audyt wszystkich zakazanych klauzul istotnych dla ich sektora - na przykład pobierając wszystkie klauzule z bankowości, ubezpieczeń lub e-commerce.

Czy klauzule niedozwolone z rejestru UOKiK obowiązują wszystkie firmy?

Tak. Gdy SOKiK uzna klauzulę za abuzywną i trafi ona do rejestru, stosowanie identycznego lub istotnie podobnego sformułowania w jakimkolwiek wzorcu umowy jest zakazane na całym rynku - nie tylko dla pozwanej firmy. UOKiK może nakładać kary do 10% rocznego obrotu za naruszenia.

Jak często aktualizowany jest rejestr UOKiK?

Rejestr jest aktualizowany w miarę wydawania nowych orzeczeń SOKiK. Nowe klauzule są dodawane regularnie, dlatego okresowy monitoring jest ważny dla zespołów compliance. Scraper pozwala to zautomatyzować poprzez zaplanowane wyszukiwania nowych wpisów.

Wypróbuj: apify.com/minute_contest/uokik-clauses-scraper

Ten artykuł jest częścią serii Polish Business Data APIs o programistycznym dostępie do polskich rejestrów publicznych.

Forem: Peter

93% of UCP profiles are broken. Here are the 3 failures that matter most.

93% of UCP profiles are broken. Here are the 3 failures that matter most.

The Data Behind the 93%

The 3 Failures That Break AI Commerce

1. Missing signing_keys - 20% of all stores

2. Missing payment_handlers - 23% of stores with UCP

3. Missing return_policy schema - 49% of all stores

The "Detected" ≠ "Ready" Trap

Real-World Example: BigCommerce Bug

What This Means for AI Commerce

Fix These in 15 Minutes

The Market Opportunity

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

The Problem: IWG License Barrier

The Solution: Ediktsdatei Scraper on Apify

Key Features

Use Cases for Compliance Teams

1. Credit Risk Assessment

2. Supply Chain Risk Management

3. Due Diligence for M&A

4. Competitive Intelligence

Technical Implementation

Basic Usage

Advanced Monitoring

Comparison with Alternatives

Compliance Benefits

6AMLD Compliance

Regulatory Reporting

Getting Started

First Run Example

Cost Analysis

Limitations and Considerations

Conclusion

Additional Resources

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

The Challenge: Cross-Border Beneficial Owner Verification

The Solution: Automated Beneficial Owner Intelligence

Poland: CRBR Beneficial Owners Scraper

Spain: Company Directory Scraper

Austria: WKO Business Directory

France: Societe.com Company Data

Automated Compliance Workflows

1. New Customer Onboarding

2. Ongoing Monitoring

3. Risk Assessment

Why Automation Beats Manual Searches

Getting Started with 6AMLD Compliance

Step 1: Assess Your Exposure

Step 2: Test Automation

Step 3: Scale Deployment

Step 4: Maintain Compliance

The Cost of Non-Compliance

Start Your 6AMLD Journey Today

UCP and ACP Need a Third Layer: Trust Rails

The 7-Day Signal (Apr 10-Apr 16)

UCP and ACP Are Reach Layers, Not Full Safety Models

Layer 1: Reach and Interoperability

Why This Week Matters More Than Another Spec Diff

The New Merchant Architecture (Practical Version)

A) Discovery and Capability Layer

B) Transaction Execution Layer

C) Trust and Liability Layer

A 30-Day Implementation Plan You Can Actually Execute

Week 1: Baseline Reach Integrity

Week 2: Checkout Determinism

Week 3: Trust Artifacts

Week 4: Liability Readiness Review

The Cost of Ignoring the Trust Layer

Where UCPtools Fits (and Where It Doesn't)

What to Do This Week

BORME Corporate Acts as Structured Data: Comparing Your Options in 2026

Option 1: LibreBOR (formerly LibreBORME)

Option 2: BORME Scraper Pro (spain-data-solutions on Apify)

Option 3: BORME Corporate Acts Parser (minute_contest on Apify)

What BORME Data Looks Like

Practical Workflow: Monitoring New Spanish Incorporations

Summary

1. Missing `signing_keys` - 20% of all stores

2. Missing `payment_handlers` - 23% of stores with UCP

3. Missing `return_policy` schema - 49% of all stores

Co robi parametr `fetchDetails`?