Procurement already keeps the supplier list that matters. It lives in SAP, Microsoft Dynamics, Business Central, Odoo, or an ERP built for the company.
That master holds vendor codes, payment terms and the firms you actually buy from. A second list, kept by hand so someone can watch public registers, is the list that goes stale.
Corween can sit behind that ERP. Sync the companies that are already there, and let risk events come back into the workflow the team already uses.
Your supplier data already lives in your ERP
A purchasing team can be responsible for hundreds or thousands of vendors. A few are strategic. Most stay quiet until something changes.
The usual check happens once, at onboarding. After that, insolvency, a new director, a change of owner or a liquidation filing can sit in a public register for weeks. Procurement hears about it when a delivery fails, or when an invoice is already in dispute.
The useful connection is the one between the vendor master you already maintain and continuous monitoring of those same companies.
From the ERP to Corween
When a supplier is created in the ERP, send Corween the facts that identify the company:
- registration number or company ID, such as an IČO or a KRS number
- country
- company name
- your internal supplier ID
Country and registration number are the identity. Corween uses them to match the company in the public registers for that country and to start monitoring. The name is what people read. Put the ERP vendor code in the subject note, so anyone opening the record can see which vendor it is.
Addresses, bank details and purchasing history stay in the ERP. Corween only needs to know which companies to watch.
A create request looks like this:
POST /api/subjects
Authorization: Bearer YOUR_API_TOKEN
{
"country": "POLAND",
"subjectType": "COMPANY",
"name": "Example Sp. z o.o.",
"registrationNumber": "0000123456",
"note": "ERP vendor V-10482"
}
The country value is the name Corween uses, for example POLAND, CZECHIA or SLOVAKIA. A VAT ID, when you have one, can go in the tax identifier. It is optional. Matching depends on the registration number.
Use the same API token on every call, for the REST API and for MCP. A nightly job, or a trigger on the vendor master, creates the subjects that are not monitored yet. If the company is already on the account, the API says so and the job moves on. The note can be updated later, when the vendor code changes. Country and registration number stay the key.
From Corween back to the ERP
Corween reads public registers and turns material changes into events. Depending on the country and the sources enabled on the account, that includes:
- insolvency and restructuring
- liquidation
- ownership changes
- director and management changes
- VAT or status changes, where a register publishes them
- other risk events, including sanctions monitoring where it is enabled
Each event names the company, describes what changed, and carries a date and a severity: INFO, MEDIUM or HIGH.
The same events can go out by email while the integration is still being built. When the event should update a system, there are two paths.
A scheduled job can read the events API, filtered by subject or by country, and write what is new onto the vendor, into a queue or into a ticket.
A webhook does the opposite. Corween calls you. Save a URL in account settings. When notifications are due, Corween sends a POST with a JSON list of events. Each item includes the company name and its registration number. That number is how you find the vendor in SAP, Dynamics or Odoo. The vendor code in the note stays on the subject in Corween, for the people reading the record.
Your endpoint can then update the ERP, post to Slack or Teams, or open a task in the procurement workflow you already run.
Three ways to integrate
REST API
Use the API when one system should talk to another.
The ERP, or a small service beside it, creates subjects and reads events on a schedule. The outcome is predictable. The same vendor master produces the same monitoring list.
ERP → Corween API → monitoring
This is the default for supplier synchronisation and for batch jobs.
Webhooks
Use a webhook when Corween should speak first.
A register changes, Corween records the event, and a POST arrives at your URL. Your service decides whether that becomes a note on the vendor, a task for the buyer, or a message in a channel.
Registry → Corween → webhook → ERP
The API keeps the supplier list current. The webhook carries the news.
MCP
Use MCP when a person, or an agent working for them, should ask a question.
The buyer stays in the conversation they already have. An AI agent connected to the ERP reaches Corween over MCP, with the same API token. It can list suppliers, add one and read events. The buyer speaks in normal language. The agent does the lookup.
AI agent → Corween MCP → supplier intelligence
The questions sound like the work:
Show me suppliers with critical changes during the last 30 days.
Check whether any of our Polish suppliers entered insolvency proceedings this week.
The agent lists events, narrows them by country when you name one, and reads the date and the severity. HIGH is what most teams mean by critical. It then answers in plain language.
MCP is the layer for questions and for assisted checks. The nightly sync stays on the API, so the agent asks about a list that is already current.
API vs MCP: which integration should you use?
Use the API when the integration must do the same thing every time.
- ERP synchronisation
- scheduled batch jobs
- automated workflows that write data into another system
- deterministic system integration
Use MCP when the next step depends on a question.
- AI assistants next to the ERP
- natural-language queries over suppliers and events
- workflows where an agent decides what to check and how to explain it
Automated workflows can use either. A job that posts new vendors belongs on the API. A buyer asking what changed for Polish suppliers this week belongs on MCP. A webhook belongs with the API: it is how a fixed process receives the event and acts.
API connects systems. MCP connects AI agents.
Most teams want both. Sync the vendor master through the API, return events through a webhook or a scheduled read, and let an agent answer the questions that are awkward to hard-code.
A practical example: SAP Business One
The pattern is the same for any ERP. SAP Business One is a clear picture of the loop.
SAP Business One
↓
Supplier master data
↓
Corween API
↓
European public registers
↓
Corween risk event
↓
Webhook
↓
SAP / Slack / Teams / procurement workflow
A vendor is released in Business One. The integration sends country, registration number, name and the vendor code in the note. Corween starts watching the registers for that country. When something material changes, the webhook returns the event. Middleware matches the registration number to the Business One vendor and opens the activity, the task or the channel message.
Dynamics 365, Business Central, Odoo and a custom ERP follow the same contract. The master-data fields differ. The monitoring contract stays the same: identify the company, then listen for events.
When an AI agent sits in front
Some teams want an assistant that already sees the ERP and the monitoring.
SAP / Dynamics / ERP
↓
AI agent
↓ MCP
Corween
↓
Supplier risk data
The agent reads vendor master data from the ERP and calls Corween for events. A buyer asks about Polish insolvency this week, or about high-severity changes in the last month, and gets an answer grounded in the companies already on the account.
Keep the API sync underneath. The agent should ask about suppliers the ERP has already sent, and create a subject when the process says a new vendor should be monitored.
What to sync, and what to leave in the ERP
A few choices keep the integration useful:
- Sync active vendors. Historical records that were never paid can stay out of monitoring.
- Treat country plus registration number as the unique key. Names change. The code in the note is for people.
- Start with one country or one purchasing organisation, then widen the job.
- Push the event into the queue, ticket or channel the team already opens.
- Let severity decide the noise. HIGH can open a task. INFO can wait for a digest, or for an agent to summarise it.
Leave the supplier list where it is
Supplier monitoring should not become another system your procurement team has to maintain.
Corween can sit behind the ERP you already run and continuously monitor the companies that already live there. The vendor master stays the source of suppliers. The API, the webhook and MCP are how that list stays watched, and how the news gets back to the people who need it.