Forem: Peter

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

Peter — Wed, 06 May 2026 10:21:17 +0000

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

OpenAI just made the biggest strategic retreat in agentic commerce, and most developers missed what it means for their stack.

In March 2026, OpenAI quietly pivoted ACP (Agentic Commerce Protocol) away from its original premise: completing purchases inside ChatGPT. The "Instant Checkout" button that was supposed to revolutionize shopping? Gone. Replaced by a merchant app model where purchases complete on the retailer's own storefront.

This isn't a bug. It's an admission that full-stack commerce is harder than discovery. And it hands the complete commerce stack to UCP by default.

What actually happened

OpenAI's ACP launched with an ambitious vision: users would discover products, compare options, and complete purchases entirely within ChatGPT. Stripe provided the payment rails. The promise was a seamless, one-tap checkout experience inside an AI conversation.

It didn't work.

CNBC reported on March 20 that "OpenAI's first try at agentic shopping stumbled." Users browsed products in ChatGPT but abandoned purchases before completing them. The in-chat checkout experience lacked sales tax infrastructure, return policy visibility, and the trust signals that mature e-commerce storefronts provide.

The pivot, detailed by Digital Commerce 360 on March 24, shifts ACP to a merchant app model:

Dedicated retailer apps inside ChatGPT (Instacart, Etsy, Shopify, Walmart)
Product discovery and comparison happens in-chat
Purchase completion happens on the merchant's own storefront (in-app browser on mobile, separate tab on desktop)

As Roger Dunn wrote in his analysis: "ACP's role shifts from universal long-tail merchant connector to plumbing for deep, bespoke retailer partnerships."

The protocol math just changed

Here's what this means for the two competing protocols:

Before the pivot (January - February 2026):

UCP: Discovery + browsing + cart + checkout (full commerce)
ACP: Discovery + Instant Checkout inside ChatGPT (full commerce)
They competed for the same stack

After the pivot (March 2026 onward):

UCP: Discovery + browsing + cart + checkout (full commerce)
ACP: Discovery + handoff to merchant storefront (discovery only)

The protocols aren't competing anymore. They're converging into different layers of the same stack. UCP owns commerce. ACP owns discovery within ChatGPT's walled garden.

As Ken Huang put it on his Substack: "Google's UCP Just Won Agentic Commerce."

What this means for developers building today

If you're an e-commerce developer deciding where to invest protocol implementation time, the math is now straightforward:

Implement UCP now. It's the only protocol that gives AI agents the full commerce capability: product catalog browsing, cart management, identity linking, and payment processing. It's co-created by Google and Shopify with 25+ partners. It's what Google AI Mode, Gemini, and an expanding ecosystem of agents use to discover and transact with stores.

ACP is becoming a discovery layer. If you want your products surfaced inside ChatGPT conversations, ACP integration matters - but as a discovery mechanism that hands off to your storefront, not as a transaction protocol.

The real implementation gap isn't protocol choice. It's quality. Most deployed UCP profiles fail at basic validation levels:

Missing signing_keys means agents can't verify your manifest
Namespace/origin mismatches break discovery before it starts
Incomplete Cart capability definitions create failed add-to-cart experiences
Identity Linking (the stable spec) is the least-implemented capability despite being the most valuable for cross-domain user recognition

At UCPtools, we scan thousands of profiles. The average score sits well below what AI agents consider reliable. Being "detected" is not the same as being "buyable."

What to build

Implement UCP on your primary store domain first. The .well-known/ucp manifest is table stakes. Make sure it validates at all four levels: structural JSON validity, business rules consistency, network reachability, and SDK-level agent simulation.
Don't skip Identity Linking. It's the stable spec that enables cross-domain user recognition. When a user browses your store on one device and returns via an AI agent on another, Identity Linking is what connects those sessions.
Add ACP as a discovery channel, not a transaction channel. The merchant app model means your ChatGPT presence should focus on product discovery and comparison, with a clean handoff to your UCP-enabled storefront where the actual purchase happens.
Monitor continuously. Protocols evolve. Specs change. Your profile that validated perfectly in April might fail in June when a capability gets promoted from draft to stable. Continuous validation catches regressions before they cost you AI agent traffic.

The bottom line

The protocol war is over before it really started. ACP pivoted to discovery. UCP owns the commerce stack by default.

The question for e-commerce developers isn't which protocol to bet on - it's whether your UCP implementation is good enough for AI agents to actually complete a purchase.

Most aren't.

Validate your UCP profile at https://ucptools.dev?utm_source=devto&utm_medium=article&utm_campaign=202605 - the free tier runs all four validation levels and simulates a real AI agent interaction against your store. If an AI agent can't buy from you, your customers can't either.

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

Peter — Fri, 01 May 2026 10:26:52 +0000

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

Most stores with a UCP profile are stuck at Grade C. Their manifest loads. Agents can see them. But they cannot buy a single thing. Here is what changes when you fix the three fields every Grade C store is missing - and how a 7-day trial makes it a 15-minute job.

The Grade C trap: visible, but not transactable

A Grade C UCP profile means structural validity. Your /.well-known/ucp returns valid JSON. An AI shopping agent can discover your store. That feels like progress.

But Grade C also means the agent hits a wall the moment it tries to do anything commercial. No payment handlers configured. No signing keys for verification. No return policy for the agent to communicate to the buyer. The agent walks away, and your store never knows it happened.

We see this pattern constantly. In the last 7 days, 59 UCP profiles were validated on UCPtools. Eleven of those stores ran the AI Agent Simulator - a real end-to-end agent interaction test. None of them completed a purchase. Zero.

Grade C means "detected." That is not the same as "can transact."

The three fields keeping you at Grade C

After scanning dozens of e-commerce domains, three failures appear on nearly every Grade C profile:

1. signing_keys - the trust layer agents require

Without a public key in your manifest, AI agents cannot cryptographically verify that your UCP responses are authentic. This is not optional. Agents check this before they take any commercial action. A missing signing_keys field is an instant trust failure.

2. payment_handlers - the "how do I pay?" gap

Agents need to know which payment methods your store accepts before they can initiate a checkout. No payment_handlers array means the agent has no path to complete a purchase. The store is technically "discoverable" but functionally invisible for any transaction.

3. Return policy schema - the confidence gap

AI agents are designed to communicate return terms to buyers before purchase. If your manifest does not include return policy information, the agent cannot answer basic buyer questions like "what happens if I need to return this?" That missing confidence costs conversions - both for the agent and for you.

These are not exotic edge cases. They are the baseline requirements that separate "the agent found your store" from "the agent bought from your store."

What the free tools tell you vs. what the trial shows you

Free UCP checkers give you a binary answer: detected or not detected. They run structural validation. They might catch a missing JSON field. But they stop there.

A UCPtools Starter trial ($9/mo, 7 days free, no credit card) gives you four layers the free tools skip:

Level 1 - Structural validation: Yes, free tools do this. Valid JSON, required fields present. This is where every Grade C store already passes.

Level 2 - Rules validation: Business logic checks. Do your namespace and origin match? Are your capability declarations internally consistent? This is where most Grade C stores start failing - but free checkers do not run these tests.

Level 3 - Network validation: Live endpoint testing. Are your UCP endpoints actually reachable over HTTPS? Do they return the correct response codes? A manifest can be structurally valid and still serve 404s to agents.

Level 4 - SDK validation (AI Agent Simulator): This is the one that matters. The simulator behaves like a real AI shopping agent - it discovers your store, reads your manifest, and attempts to complete a purchase. It shows you exactly where the agent fails and why. Eleven stores ran this in the last 7 days. All eleven hit failures that structural validation alone would never catch.

From Grade C to Grade A: the 15-minute path

Here is what the upgrade looks like in practice:

Step 1: Run the full scan (2 minutes)

Start your trial and point UCPtools at your domain. The 4-level scan completes in under 90 seconds. You get a report that looks nothing like a "detected/not detected" badge - it is a prioritized list of failures ranked by severity, with exact fix recommendations.

Step 2: Generate your signing keys (3 minutes)

UCPtools generates a key pair for you through the hosted profile generator. Copy the public key into your manifest. The tool validates the placement so you know it is right before you deploy.

Step 3: Configure payment handlers (5 minutes)

Map your existing payment stack (Stripe, Shopify Payments, PayPal) to the UCP payment handler format. The trial shows you the exact JSON structure your manifest needs based on what your store already supports.

Step 4: Add return policy schema (3 minutes)

Structured return policy data that agents can parse and communicate. The trial's hosted profile builder includes a template you fill in once and deploy.

Step 5: Re-scan and simulate (2 minutes)

Run validation again. Run the AI Agent Simulator. Watch the agent discover your store, verify your keys, read your payment handlers, and complete a purchase simulation. Grade A means the agent can do everything a human shopper can do - find you, browse, and buy.

Why the trial matters (and why it is free)

Nobody pays $9 to see a validation report. They pay $9 because the report tells them something the free tools never will: whether AI agents can actually buy from their store, and exactly how to fix it if they cannot.

The 7-day trial exists because this is not something you evaluate from a marketing page. You need to see your own domain's results. You need to run the simulator against your own store. The trial gives you full access to do exactly that, with no credit card required.

If your store passes structural validation but you have never run the simulator, you do not know if your UCP profile works. You just know it loads.

Scan your store free

Start your 7-day free trial at ucptools.dev - no credit card required. Run a full 4-level validation against your domain and see exactly where your store stands with AI shopping agents.

Written by the team at UCPtools - the only toolkit that validates, monitors, and optimizes your UCP business profile for AI agent discoverability. Questions? Find us on X @ucptoolsdev.

UCP Validation for Agencies: How to Audit AI Readiness Across Every Client Domain

Peter — Wed, 29 Apr 2026 11:02:37 +0000

If you're a GEO consultant or agency managing ecommerce clients, you've probably been asked some version of this question:

"Can AI agents find my store? How do I know?"

The honest answer, until recently, was: you don't. There was no standardized way to measure AI agent discoverability. That changed with UCP (Universal Commerce Protocol) - the open standard from Google and Shopify that gives AI shopping agents a machine-readable entry point to any store.

Now there is something measurable. And if you're the one measuring it for your clients, that's a service worth charging for.

Why Agencies Should Care About UCP Audits

Google AI Mode, Microsoft Copilot, ChatGPT, and Perplexity are all building agentic commerce capabilities. Microsoft announced GA of UCP feeds in Merchant Center on April 21, 2026. Over 12,000 merchants have published UCP profiles as of Q1 2026.

Your clients are going to ask about this. Some already have. The agencies that can answer with data - not hand-waving - will win those conversations.

Here's what makes UCP audits a natural fit for agencies:

It's per-domain. Each client's hosting stack, CDN, and certificate chain breaks differently. A profile that works on Shopify fails on WooCommerce for entirely different reasons.
It's recurring. UCP validation isn't a one-time setup. Deploys break endpoints. CDN caches serve stale schemas. Certificate renewals don't propagate. The profile that passed last month can silently fail this month.
It's reportable. UCP validation produces a numerical AI readiness score (0-100) with specific, fixable issues. That's the kind of deliverable clients understand.

The Agency Audit Framework

Here's a repeatable process for running UCP audits across a client portfolio. It works whether you manage 3 domains or 300.

1. Baseline Scan: Does the Profile Exist?

Before anything else, check whether each client domain serves a UCP manifest at /.well-known/ucp.

https://client-store.com/.well-known/ucp

Three outcomes:

404 / No manifest - The store is invisible to AI agents. Full stop. This is your biggest finding and your clearest upsell.
Manifest exists but invalid JSON - Broken deployment or misconfigured server. Quick fix, high impact.
Valid manifest - Move to deeper validation.

In our experience, roughly 70% of ecommerce stores don't serve a UCP manifest at all. For the ones that do, about 60% have issues at deeper validation levels.

2. Four-Level Validation

UCP validation isn't binary (pass/fail). There are four distinct levels, and each catches different categories of issues:

Level	What It Checks	Common Failures
1. Structural	JSON syntax, required fields, version format	Missing `ucp` root, wrong version format
2. Compliance	Protocol rules: namespaces, HTTPS, signing keys	Namespace mismatches, missing signing keys (42% of L2 failures), HTTP endpoints
3. Network	Do declared URLs actually resolve?	CDN 404s, stale schemas, malformed JWK keys
4. Agent Simulation	Full checkout lifecycle test	Backend returns 500 on cart creation, state machine failures

Most validators - including the free ones your clients might have tried - only check Level 1. That gives false confidence. A Level 1 pass with Level 3 failures means the profile looks correct but agents can't actually use it.

For agencies, Level 3 is the most valuable finding. These are infrastructure-drift issues that only surface after deploys, CDN changes, or certificate renewals. They're invisible to the developer who wrote the profile but obvious to an auditor running regular checks.

3. Score and Categorize

After running validation, each domain gets an AI readiness score (0-100) and a letter grade:

Grade	Score	What It Means
A	90-100	AI agents can discover, browse, and transact
B	70-89	Discoverable with minor issues
C	50-69	Detected but can't complete transactions
D	20-49	Major issues blocking agent interaction
F	0-19	Effectively invisible

The Grade C trap is the most common: the profile exists and passes basic checks, but missing signing keys or broken endpoints prevent any actual transaction. Your client thinks they're "UCP ready" because they have a manifest file. They're not.

4. Build the Client Report

A useful client report contains:

Score and grade for each domain
Issue breakdown by validation level (structural, compliance, network, simulation)
Specific fixes with estimated effort (most Level 2 fixes take minutes)
Comparison to previous audit if this is a recurring engagement
Competitive context - how do they compare to others in their vertical?

The key metric clients care about: "Can AI agents buy from my store?" Frame everything around that question. A score of 62 means "AI agents can find you but can't complete a purchase." That's concrete enough to drive action.

What to Check Per Platform

UCP issues cluster differently by ecommerce platform. Knowing the common patterns saves audit time:

Shopify

UCP profile served via app proxy (path configuration matters)
Payment handler configuration usually correct (Shopify handles this)
Watch for: signing key rotation gaps, custom app conflicts

WooCommerce

Profile typically served via WordPress plugin or .htaccess rewrite
Watch for: HTTP endpoints (mixed content from plugin misconfiguration), schema URL 404s after plugin updates

BigCommerce

Common issue: dev.ucp.shopping service missing required spec field (UCP_INVALID_SERVICE)
Watch for: trailing slashes on API endpoints

Magento / Adobe Commerce

Custom module required for /.well-known/ucp routing
Watch for: namespace mismatches when using third-party extensions, GraphQL endpoint schema drift

Custom / Headless

Most flexibility, most failure modes
Watch for: CORS blocking agent preflight requests, endpoint URLs changing between environments

Automating Portfolio Audits

Running manual checks across 10+ domains doesn't scale. Two automation approaches:

CI/CD Integration (Per Client)

If you have access to client repos, the ucp-validate GitHub Action fails the build when the AI readiness score drops below a threshold:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'client-store.com'
    min-score: 70

This catches regressions at deploy time - before they affect agent traffic.

Scheduled Monitoring (Portfolio-Wide)

For ongoing monitoring without repo access, run validation against each client domain on a schedule. The UCPtools validator supports domain-level validation via URL - no code access needed.

Track scores over time. A domain that drops from 85 to 62 between audits means something broke in production, and you're the one catching it before the client's AI-driven traffic disappears.

Positioning This as a Service

UCP auditing fits naturally into existing GEO/SEO service packages:

One-time audit - Baseline scan across all client domains with a findings report. Natural entry point.
Monthly monitoring - Recurring validation with score tracking and regression alerts. Retainer model.
Implementation support - Fix the issues the audit found. Scope varies by platform (Shopify is usually hours, custom builds are days).

The pitch to clients: "Your SEO drives traffic to your store. UCP drives AI agent traffic. We monitor both."

What makes this defensible: UCP validation requires understanding the spec, the four validation levels, and platform-specific patterns. A generic SEO tool can't do this. You can.

Getting Started

Run a free validation against one of your client domains at ucptools.dev. See the score, the issues, and which level caught them.
Repeat for your portfolio. Note which clients have no manifest at all vs. which have broken ones.
Build the report. Score, grade, issues, fixes. Send it to the client.
Set up monitoring. Catch regressions before they cost AI traffic.

The agencies that can quantify AI discoverability will own this conversation. The ones that can't will be explaining why they didn't notice their client's store disappeared from ChatGPT.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

I Built Skills That Let AI Agents Query 14 European Government Registries

Peter — Tue, 28 Apr 2026 17:50:50 +0000

TL;DR

I built 14 Apify actors that scrape official government registries across Poland, Spain, Austria, and France
To make them accessible from AI coding agents, I packaged them as 6 open-source skills in the getregdata repo
One install command gives you access across 45+ AI agents - Claude Code, GitHub Copilot, Cline, Codex, Amp, and more
The skills provide registry-specific analysis frameworks and let you query live data through the Apify API
Install: skills add Nolpak14/getregdata -g -y

Why Government Registry Data Is Hard

If you have ever tried to programmatically access European government registries, you know the pain. Each country has its own set of portals, each with its own quirks:

Poland's KRS (National Court Register) deliberately anonymizes board member names in its API - returning L****** instead of full names - while the same data is available unredacted in PDF extracts from the same portal
Poland's CRBR (Beneficial Owners Register) has no API at all - just a CAPTCHA-protected web form that accepts one company at a time
Poland's EKW (Land Registry) blocks all datacenter IPs - you need residential Polish proxies to access property ownership data
Spain's BORME (Corporate Gazette) publishes 500+ corporate acts daily as unstructured gazette text with no machine-readable format
Austria's Ediktsdatei (Insolvency Publications) requires an IWG license for the official API - but the public web portal has no such restriction
France's Societe.com aggregates data from INSEE, INPI, and BODACC behind aggressive anti-bot measures

Each registry is a separate engineering challenge. Different authentication, different anti-scraping measures, different data formats, different legal frameworks.

The Actor Suite: 14 Registries, 4 Countries

Over the past months I built Apify actors for all of these. Each actor handles the specific technical challenges of its registry and returns clean, structured JSON.

Poland (9 registries)

Registry	What You Get	Records
KNF - Financial Supervision Authority	Payment institutions, e-money issuers, lending companies	75,000+
MSiG - Court Gazette (Monitor Sadowy)	Bankruptcy declarations, restructuring, liquidation notices	2001-present
KRS - National Court Register	Full non-anonymized board member names from PDF extracts	800,000+ companies
KRZ - National Debtor Registry	Bankruptcy, restructuring, enforcement proceedings	9 search modes
eKRS - Financial Statements	Balance sheets, P&L, assets, equity, revenue, net profit	Official filings
EKW - Land Registry	Property ownership, mortgages, easements, restrictions	25 million entries
UOKiK - Consumer Protection	Court-ruled prohibited contract clauses	7,500+ clauses
CRBR - Beneficial Owners	Ultimate beneficial owners (UBO) for AML compliance	All KRS entities
BDO - Waste Registry	Waste management entity registrations and permits	674,000+ entities

Spain (2 registries)

Registry	What You Get
BORME - Corporate Gazette	Daily incorporations, officer appointments, capital changes, dissolutions
Registro Mercantil - Company Directory	NIF, officers, CNAE codes, legal form, IRUS, EUID

Austria (2 registries)

Registry	What You Get
Ediktsdatei - Insolvency Publications	Bankruptcy, restructuring, debt regulation proceedings - no IWG license needed
WKO - Chamber of Commerce Directory	620,000+ businesses with phone, email, website, trade licenses

France (1 registry)

Registry	What You Get
Societe.com - Company Data	SIREN, directors with roles, financials, shareholders, subsidiaries, brands

All actors are pay-per-result with no subscriptions. Pricing ranges from $0.003 to $0.01 per result depending on the registry. A free Apify account includes $5 credits - enough for 100-1,600 lookups.

From Actors to AI Agent Skills

The actors work great when you know exactly which registry to query. But for many users, the real question is: "I need to check this Polish company - where do I even start?"

That is where skills come in. Skills are modular packages that give AI coding agents specialized knowledge. When you install a skill, your agent learns how to handle domain-specific tasks - in this case, querying European government registries.

I packaged the 14 actors into 6 skills organized by workflow:

Skill	What It Does	Registries Used
`regdata`	Router - identifies which registry you need	All 14
`regdata-kyc-aml`	Beneficial ownership, financial licenses, board members	CRBR, KNF, KRS, Societe.com, WKO, Spain Dir
`regdata-credit-risk`	Insolvency proceedings, court gazette, financial statements	KRZ, MSiG, eKRS, Ediktsdatei, BORME
`regdata-property`	Polish land registry - ownership, mortgages, encumbrances	EKW, KRS, CRBR
`regdata-compliance`	Prohibited contract clauses, waste management registrations	UOKiK, BDO
`regdata-lead-gen`	Company directors, business contacts, new incorporations	KRS, WKO, Spain Dir, Societe.com, BORME

Each skill includes:

Analysis frameworks specific to the registries it covers (e.g., how to interpret Polish land registry sections, what Austrian insolvency proceeding types mean)
Data extraction instructions for both MCP mode (direct tool calls) and API mode (curl/SDK)
Output interpretation guides so you know what the returned data actually means

Installation

One command installs all 6 skills globally across every supported agent:

skills add Nolpak14/getregdata -g -y

This works with 45+ AI agents including Claude Code, GitHub Copilot, Cline, Codex, Amp, Antigravity, and more. The skills are installed to ~/.agents/skills/ and symlinked to agent-specific locations.

How It Works in Practice

Example 1: Check beneficial owners of a Polish company

You open Claude Code (or any supported agent) and type:

Check who owns the Polish company with NIP 5213103635 in CRBR

The regdata-kyc-aml skill activates. It knows that CRBR is Poland's beneficial owners registry and that NIP is the correct identifier. It guides the extraction:

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

run = client.actor("regdata/crbr-beneficial-owners-scraper").call(
    run_input={"nip": "5213103635"}
)

for item in client.dataset(run["defaultDatasetId"]).list_items().items:
    print(f"Company: {item['name']}")
    for owner in item.get("beneficialOwners", []):
        print(f"  UBO: {owner['firstName']} {owner['lastName']}")
        print(f"  Ownership: {owner.get('sharePercentage', 'N/A')}%")

If you have the Apify MCP server configured, the agent can run the actor directly through tool calls without writing any code.

Example 2: Monitor Spanish corporate gazette for new incorporations

Search BORME for new company incorporations in Barcelona from last week

The regdata-credit-risk skill activates (BORME corporate acts). It builds the right query:

run = client.actor("regdata/borme-corporate-acts-scraper").call(
    run_input={
        "dateFrom": "2026-04-21",
        "dateTo": "2026-04-28",
        "provinces": ["Barcelona"]
    }
)

Example 3: Extract Polish land registry data

Pull EKW data for property WR1K/00094598/3

The regdata-property skill activates. It knows the KW number format, that EKW requires residential Polish proxies, and how to interpret the four sections (Dzial I-IV):

run = client.actor("regdata/ekw-ksiegi-wieczyste-scraper").call(
    run_input={
        "kwNumbers": ["WR1K/00094598/3"],
        "viewType": "aktualna",
        "sections": ["all"]
    }
)

The skill then explains what each section means - Dzial II for ownership, Dzial III for restrictions and easements, Dzial IV for mortgages - so you can actually interpret the raw data.

Example 4: Get non-anonymized KRS board members

Extract board members for Polish KRS number 0000019193

The regdata-lead-gen skill knows that the official KRS API anonymizes names, and that the actor works around this by extracting full names from PDF court extracts:

run = client.actor("regdata/krs-fullnames-scraper").call(
    run_input={
        "krsNumbers": ["0000019193"],
        "extractType": "aktualny"
    }
)

You get full first and last names of board members, supervisory board, and shareholders - not the L****** that the API returns.

What Makes This Different from a Generic Scraping Skill

The value of domain-specific skills is that they carry registry knowledge that a generic web scraping tool does not have:

The skill knows that EKW requires residential Polish proxies (datacenter IPs are blocked)
It knows that KRS anonymizes names in the API but not in PDFs
It knows that BORME Section A publishes corporate acts while Section B publishes financial data
It knows that Austria's Ediktsdatei has Konkursverfahren (bankruptcy) and Sanierungsverfahren (restructuring) and what the difference means
It knows that a Polish KW number follows the format CODE/NUMBER/DIGIT (e.g., WR1K/00094598/3)
It knows that CRBR defines beneficial ownership as >25% shares or voting rights

This registry-specific knowledge means your AI agent can handle queries correctly without you needing to read documentation for each portal.

Authentication Setup

The skills provide analysis frameworks for free, but extracting live data requires an Apify API token:

export APIFY_TOKEN=apify_api_xxxxx

Get your token by creating a free Apify account - includes $5 credits, enough for hundreds of registry lookups.

Pricing Quick Reference

All actors use pay-per-result pricing. No subscriptions, no minimum commitments.

Registry	Cost per Result
KNF, UOKiK, WKO, BORME	$0.003
MSiG, BDO	$0.004
Ediktsdatei, Spain Dir, Societe.com	$0.005
KRZ	$0.006
KRS Board, eKRS, CRBR	$0.008
EKW	$0.01

Typical cost for a full company check (CRBR + KNF + KRS Board): ~$0.019.

Technical Details

The skills repo follows the standard skills ecosystem structure:

getregdata/
  skills/
    regdata/SKILL.md              # Router
    regdata-kyc-aml/SKILL.md      # + references/
    regdata-credit-risk/SKILL.md  # + references/
    regdata-property/SKILL.md     # + references/
    regdata-compliance/SKILL.md   # + references/
    regdata-lead-gen/SKILL.md     # + references/

Each SKILL.md uses YAML frontmatter for trigger matching:

---
name: regdata-kyc-aml
description: "Extract beneficial ownership data from Poland's CRBR registry,
  financial license status from KNF, non-anonymized board members from KRS..."
metadata:
  version: 1.0.0
  author: regdata
  triggers:
    - "CRBR beneficial owner lookup"
    - "check KNF registry"
    - "KRS board members extract"
    - "Polish beneficial owners"
---

Triggers are registry-specific, not generic domain terms. The skill activates when you mention a specific European registry, not when you ask about "KYC" or "compliance" in general.

The references/ subdirectories contain detailed interpretation guides (land registry section breakdowns, insolvency proceeding types across jurisdictions, UOKiK clause categories) that the agent loads on demand.

Source Code and Contributing

The skills are MIT licensed and open source:

GitHub: github.com/Nolpak14/getregdata

The underlying Apify actors are available on the Apify Store under the regdata publisher profile.

If you work with government registries in other EU countries and want to contribute skills for those, PRs are welcome.

What Is Next

More registries: Germany (Handelsregister, Insolvenzbekanntmachungen), Italy (Registro Imprese), Netherlands (KVK)
Deeper cross-registry workflows: automated multi-country due diligence pipelines
Scheduled monitoring: get notified when a company's registry data changes

Install: skills add Nolpak14/getregdata -g -y

Actors: apify.com/regdata

GitHub: github.com/Nolpak14/getregdata

This article is part of the European Registry Data series covering programmatic access to government registries across the EU.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Peter — Sun, 26 Apr 2026 15:55:30 +0000

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

We scanned 111 e-commerce stores. 35 of them have UCP profiles that pass validation. But not a single one can actually complete a purchase with AI agents.

Here's why: these "Grade C" stores all share the same 3 critical missing fields.

The Grade C Trap: Detection ≠ Readiness

Every store in the Grade C category (score: 60-79) has UCP manifest files that basic validators like UCPChecker.com report as "valid." They pass structural validation, network connectivity, and even basic schema checks.

But when AI agents actually try to interact with these stores, they fail. Every single time.

The problem isn't that these stores lack UCP profiles. The problem is that their profiles lack 3 specific fields that AI agents need to complete transactions.

The 3 Missing Fields Break AI Commerce

1. Missing `signing_keys` - The Trust Gap

What it is: Cryptographic verification that the UCP manifest hasn't been tampered with.

Why agents need it: AI agents need to verify that the UCP profile they're interacting with is authentic and hasn't been maliciously modified.

Impact: Without signing keys, AI agents cannot trust the UCP profile, making the entire interaction insecure.

Prevalence: 19.8% of stores with UCP profiles lack signing keys, but 100% of Grade C stores are missing them.

2. Missing `payment_handlers` - The Purchase Blocker

What it is: Configuration that tells AI agents how to process payments for the store.

Why agents need it: AI agents need to know which payment methods to use, how to format payment requests, and how to handle payment processing.

Impact: Without payment handlers, AI agents cannot complete purchases. They can discover the store and browse products, but they can't buy anything.

Prevalence: 22.5% of stores with UCP profiles lack payment handlers, but 100% of Grade C stores are missing them.

3. Missing `return_policy` Schema - The Trust Builder

What it is: Structured data about return policies, warranties, and refund terms.

Why agents need it: AI agents need to show customers trust signals before making purchases. Return policies are one of the most important trust signals for e-commerce.

Impact: Without return policy schema, AI agents cannot display return terms, build customer trust, or handle post-purchase service.

Prevalence: 48.6% of all stores lack return policy schema, but 100% of Grade C stores are missing them.

Why This Matters for Agentic Commerce

The Grade C pattern reveals a critical gap in current UCP implementations:

Stores pass "presence" validation but fail "interaction" validation.

This means:

AI discovery works (agents can find the store)
Product browsing works (agents can see products)
But purchasing fails (agents cannot complete transactions)

For agentic commerce to work, we need to move beyond "is UCP present?" to "can UCP actually facilitate commerce?"

How to Fix Your Grade C Profile

The good news: these are configuration issues, not platform limitations. Here's how to address each:

1. Add Signing Keys

{
  "signing_keys": [
    {
      "key_id": "your-key-id",
      "public_key": "your-public-key-here",
      "algorithm": "ES256"
    }
  ]
}

2. Configure Payment Handlers

{
  "payment_handlers": [
    {
      "payment_method": "credit_card",
      "supported_networks": ["visa", "mastercard", "amex"],
      "capabilities": ["supports_installments", "supports_3d_secure"]
    },
    {
      "payment_method": "paypal",
      "capabilities": ["supports_paypal_vault"]
    }
  ]
}

3. Add Return Policy Schema

{
  "return_policy": {
    "return_window_days": 30,
    "return_shipping_paid_by": "merchant",
    "refund_method": "original_payment_method",
    "exceptions": ["final_sale_items", "custom_products"],
    "restocking_fee_percent": 0
  }
}

The BigCommerce Platform Bug

Our scans reveal a specific pattern affecting BigCommerce stores:

Issue: dev.ucp.shopping service missing required spec field
Issue: REST transport missing required schema field
Result: All report UCP_INVALID_SERVICE errors

This appears to be a platform-level issue in BigCommerce's UCP implementation. BigCommerce merchants should verify their REST schema fields and contact BigCommerce support if these fields are missing.

Who's Affected?

All 35 Grade C stores share these exact same failures, including:

SaaS agencies: obundle.com, papathemes.com
Fashion DTC: allbirds.com, brooklinen.com, chubbiesshorts.com, fashionnova.com
Home Decor: curatedhomedecor.com, interiordelights.net, feldkampsfurniture.com
Beauty: kyliecosmetics.com

These aren't small, unknown stores. These are established brands with UCP profiles that "pass validation" but fail at AI commerce.

The Reality Check

65% of stores have zero UCP profiles.
Zero stores are fully AI-agent ready.
35 stores have "broken but detectable" UCP profiles.

The state of agentic commerce readiness is worse than most merchants realize. Having a UCP profile isn't enough. Your profile actually needs to work with AI agents.

Test Your AI Readiness

Don't trust basic validation. Test your actual AI commerce readiness:

Check your signing keys: Can your manifest be cryptographically verified?
Test payment handlers: Can AI agents process payments on your store?
Verify return policy: Do agents have access to your return terms?

The gap between "UCP detected" and "AI commerce ready" is where most merchants are stuck. Fixing these 3 fields is the bridge from discovery to actual transactions.

Data from UCPtools AI Readiness Index (111 domains scanned, April 13, 2026)

Test your store's actual AI readiness at ucptools.dev?utm_source=devto&utm_medium=article&utm_campaign=202604

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

Peter — Fri, 24 Apr 2026 09:54:57 +0000

On January 8, 2026, Microsoft launched Copilot Checkout on ACP - OpenAI's Agentic Commerce Protocol, powered by Stripe.

104 days later, on April 22, Microsoft announced general availability of UCP feeds in Merchant Center. Target was the launch partner. The same day, Ulta Beauty went live with agentic commerce, linking 46 million loyalty members through UCP.

Microsoft didn't just add a second protocol. They switched horses mid-race.

The question nobody's answering clearly: what does UCP have that ACP doesn't?

The answer is one capability: Identity Linking.

The Loyalty Problem AI Agents Create

Think about what happens when an AI agent shops on your behalf.

It finds a product. Compares prices. Adds to cart. Checks out. Every step works. But it checks out as a guest.

The agent doesn't know you're a Target Circle member. It doesn't know you have 50,000 reward points. It doesn't know you qualify for member-only pricing on the item it just found.

Every AI-mediated purchase becomes a guest checkout. Merchants lose their most valuable signal: who this customer actually is.

This isn't an edge case. Target Circle has tens of millions of members. Ulta has 46 million. Sephora, Best Buy, Gap - all UCP endorsers - have massive loyalty programs. When AI agents ignore all of that, merchants lose the customer relationship they spent years building.

The protocol that solves this wins. That's why Microsoft switched.

How Identity Linking Actually Works

Identity Linking is a stable capability in the UCP spec (not draft, not experimental). It's been there since the January 2026 launch.

The namespace is dev.ucp.common.identity_linking - note it's under common, not shopping. This trips up a lot of implementations.

Here's what the capability declaration looks like in your /.well-known/ucp profile:

{
  "name": "dev.ucp.common.identity_linking",
  "version": "2026-01-11",
  "spec": "https://ucp.dev/latest/specification/identity-linking/",
  "schema": "https://ucp.dev/schemas/common/identity_linking.json",
  "config": {
    "supported_mechanisms": [
      {
        "type": "oauth2",
        "issuer": "https://yourstore.com"
      }
    ]
  }
}

The flow uses standard OAuth 2.0 Authorization Code (RFC 6749). Nothing exotic:

Agent reads your UCP profile and sees you support Identity Linking
Agent discovers your OAuth server via RFC 8414 at /.well-known/oauth-authorization-server
Agent requests authorization on the user's behalf
User sees a one-time consent prompt (inside Copilot or Gemini)
Agent gets an access token scoped to ucp:scopes:checkout_session
Every subsequent checkout carries member pricing, points, preferences

The critical insight: one consent, persistent identity. The user approves once. After that, the agent carries their loyalty membership into every future session with that merchant. No re-auth. No per-transaction prompts.

Your OAuth server needs to publish a metadata endpoint per RFC 8414:

{
  "issuer": "https://yourstore.com",
  "authorization_endpoint": "https://yourstore.com/oauth/authorize",
  "token_endpoint": "https://yourstore.com/oauth/token",
  "scopes_supported": ["ucp:scopes:checkout_session"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic"]
}

Note: the OAuth endpoints are NOT declared in the UCP profile. They're discovered dynamically via RFC 8414. The profile only declares the issuer URL.

Target Circle in Copilot: What the Flow Looks Like

Here's what Microsoft built with Target as the launch partner:

You ask Copilot to find running shoes under $80
Copilot queries Target's UCP endpoint, finds matching products
You pick a shoe. Copilot starts checkout
Copilot sees Identity Linking in Target's profile. Prompts: "Connect your Target Circle account?"
You approve. OAuth happens behind the scenes
Checkout continues - but now with your Circle discount applied, your email pre-filled, your reward points available
Next time you shop at Target through Copilot, step 4 is skipped. Your identity persists

This is why Microsoft specifically called out Identity Linking in their Merchant Center announcement. It's not a nice-to-have feature - it's the mechanism that makes loyalty programs survive the shift to AI-mediated commerce.

Why ACP Can't Do This

ACP uses Stripe delegated tokens. A Stripe token represents a payment credential - a card, a wallet, a bank account.

A Stripe token knows your card number. It does not know you're a rewards member. It does not know your loyalty tier. It does not carry member pricing.

ACP has no OAuth identity layer. No account linking mechanism. No way for an agent to say "this shopper is customer #4821 with Gold status."

This is a structural gap, not a missing feature. ACP was designed for payment delegation. UCP was designed for the full commerce lifecycle - including identity.

When Microsoft needed loyalty programs to work in Copilot Shopping, ACP couldn't deliver. UCP could. 104 days was all it took to make the switch.

Implementation: Adding Identity Linking to Your Profile

If you have a loyalty program and want it to work with AI agents, here's what you need:

1. Add the capability to your UCP profile

Add the dev.ucp.common.identity_linking entry to your capabilities array (see the JSON example above). Common namespace - not shopping.

2. Set up your OAuth server

You need a standard OAuth 2.0 Authorization Server with a metadata endpoint at /.well-known/oauth-authorization-server. If you already support OAuth for mobile apps or partner integrations, you're most of the way there.

3. Watch for these validation failures

Our validator catches 4 Identity Linking-specific issues:

Error Code	What Went Wrong
`UCP_IDENTITY_MISSING_MECHANISMS`	No `config.supported_mechanisms` in your capability
`UCP_IDENTITY_INVALID_MECHANISM`	Mechanism entry missing required `type` field
`UCP_IDENTITY_MISSING_ISSUER`	OAuth2 mechanism without an `issuer` URL
`UCP_IDENTITY_ISSUER_NOT_HTTPS`	Issuer URL uses HTTP instead of HTTPS

The most common failure: declaring the capability but forgetting the config block entirely. A Level 1 validator (JSON structure only) won't catch this. You need Level 2 compliance validation.

What To Do Next

Check if your profile declares Identity Linking - if you have a loyalty program and it's missing, your members are invisible to AI agents
Validate your Identity Linking config at ucptools.dev - the validator checks all 4 error codes and tells you exactly what to fix
Add UCP validation to CI/CD - catch regressions before agents do (GitHub Action)
Test the OAuth flow end-to-end - a valid profile means nothing if the OAuth metadata endpoint returns a 404

Microsoft made their bet. Target and Ulta are live. The Identity Linking spec is stable and validated by multiple agent platforms. If you have a loyalty program, this is the capability that makes it travel with your customers into AI commerce.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

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

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.

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("regdata/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('regdata/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/regdata/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("regdata/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('regdata/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/regdata/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("regdata/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('regdata/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/regdata/poland-krs-financial-scraper

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

Forem: Peter

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

What actually happened

The protocol math just changed

What this means for developers building today

What to build

The bottom line

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

The Grade C trap: visible, but not transactable

The three fields keeping you at Grade C

What the free tools tell you vs. what the trial shows you

From Grade C to Grade A: the 15-minute path

Why the trial matters (and why it is free)

Scan your store free

UCP Validation for Agencies: How to Audit AI Readiness Across Every Client Domain

Why Agencies Should Care About UCP Audits

The Agency Audit Framework

1. Baseline Scan: Does the Profile Exist?

2. Four-Level Validation

3. Score and Categorize

4. Build the Client Report

What to Check Per Platform

Shopify

WooCommerce

BigCommerce

Magento / Adobe Commerce

Custom / Headless

Automating Portfolio Audits

CI/CD Integration (Per Client)

Scheduled Monitoring (Portfolio-Wide)

Positioning This as a Service

Getting Started

I Built Skills That Let AI Agents Query 14 European Government Registries

TL;DR

Why Government Registry Data Is Hard

The Actor Suite: 14 Registries, 4 Countries

Poland (9 registries)

Spain (2 registries)

Austria (2 registries)

France (1 registry)

From Actors to AI Agent Skills

Installation

How It Works in Practice

Example 1: Check beneficial owners of a Polish company

Example 2: Monitor Spanish corporate gazette for new incorporations

Example 3: Extract Polish land registry data

Example 4: Get non-anonymized KRS board members

What Makes This Different from a Generic Scraping Skill

Authentication Setup

Pricing Quick Reference

Technical Details

Source Code and Contributing

What Is Next

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

The Grade C Trap: Detection ≠ Readiness

The 3 Missing Fields Break AI Commerce

1. Missing signing_keys - The Trust Gap

2. Missing payment_handlers - The Purchase Blocker

3. Missing return_policy Schema - The Trust Builder

Why This Matters for Agentic Commerce

How to Fix Your Grade C Profile

1. Add Signing Keys

2. Configure Payment Handlers

3. Add Return Policy Schema

The BigCommerce Platform Bug

Who's Affected?

The Reality Check

Test Your AI Readiness

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

The Loyalty Problem AI Agents Create

How Identity Linking Actually Works

Target Circle in Copilot: What the Flow Looks Like

Why ACP Can't Do This

Implementation: Adding Identity Linking to Your Profile

What To Do Next

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.

1. Missing `signing_keys` - The Trust Gap

2. Missing `payment_handlers` - The Purchase Blocker

3. Missing `return_policy` Schema - The Trust Builder

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`?