Migrating from Middesk to Cobalt Business Monitoring: API Integration Guide

Executive Summary: Before any of the mechanics, one thing has to be said plainly, because getting it wrong turns a migration into an outage. This is not a like-for-like swap. Middesk's monitoring covers Secretary of State registrations, TIN registrations, watchlist hits, bankruptcies, and UCC liens. Cobalt's Business Monitoring covers the Secretary of State record only. Moving the SOS layer across is a migration. Switching everything off and expecting parity is a coverage loss, and it is a coverage loss in the categories most likely to matter to a compliance team.

What actually transfers, and what does not?

Map the categories before writing any code. Their documentation states that enrolled businesses are tracked for "important changes like bankruptcy filings, registration updates, and lien activity,"^[1] with dedicated coverage for watchlist hits and for "new and terminated UCC liens."^[2]

The four rows marked no are not a roadmap gap. Those records live in different systems entirely, so a product that re-reads a Secretary of State record cannot reach them regardless of how often it runs. Cobalt's own OFAC documentation was updated on August 3, 2026 to state explicitly that Business Monitoring does not close the sanctions re-screening gap.

Therefore step one of any migration plan is a replacement plan for those four categories, whether that means retaining a Middesk subscription for them, moving them to existing systems, or accepting a documented reduction in coverage with sign-off. Deciding that after cutover is how a monitoring programme develops a hole nobody notices until an audit.

What does the field mapping look like?

The good news is that both products read the same underlying public record, so the Secretary of State fields correspond closely.

Middesk's `registration.created` payload includes `name`, `status`, `sub_status`, `status_details`, `jurisdiction`, `entity_type`, `file_number`, `addresses`, `officers`, `registered_agent`, `registration_date`, `state`, and a `source` URL pointing at the state search page.^[3] Cobalt's Secretary of State search returns the equivalent record from the state, and for a single lookup the call is:

curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=TX" \
  -H "x-api-key: YOUR_API_KEY"

Three mapping cautions matter more than the field names.

• Status vocabularies are not identical. Middesk exposes `status`, `sub_status` and `status_details` as separate fields. Any normalization your code performs against those three needs re-deriving rather than porting, because the same state condition may be represented differently.

• Your internal taxonomy is the stable layer. If you currently map vendor statuses into your own risk categories, that mapping is the asset. Rebuild the vendor-to-internal translation and leave everything downstream untouched.

• Identifiers do not carry over. Middesk's `business_id` is theirs. You will need your own borrower key joined to whatever identifier the new integration uses, and that join table is worth building before cutover rather than during.

The `file_number` and `state` pair is usually the most reliable natural key for reconciling records across vendors, since it comes from the state rather than from either vendor.

How does the delivery model change?

This is the largest architectural difference and the one that determines most of the engineering effort.

Middesk pushes. You host a webhook endpoint, subscribe to events, and handle them as they arrive. Their documented pattern for status is to subscribe to `registration.created` and `registration.updated` and "detect a change to any field on an existing registration," using the `previous_attributes` object to see what moved.^[3] They publish granular events including `name.created`, `name.deleted`, `person.created`, `person.deleted`, `address.created`, and `address.deleted`.^[4]

Cobalt pulls on a schedule you configure from 1 to 30 days, and reports what changed against the previous check with changes classified by severity. Each completed check costs 1 credit from the shared pool.^[5]

What that means practically for the migration:

• You gain control of timing and lose delivered deltas. A pull model lets you set the interval against your own clock. It also means the comparison against the prior record is part of the system rather than arriving in the payload.

• Webhook infrastructure may become unnecessary for this feed. If it exists only for monitoring, retiring it removes signature verification, retry handling, and an availability commitment.

• Severity arrives supplied rather than derived. If you built field-level severity logic on top of granular events, some of it is replaced rather than ported.

• Scheduling becomes your responsibility. Most servicing teams already run scheduled jobs against borrower records, so this is usually a smaller lift than it sounds.

The migration risk is not in the field mapping. It is in the interpretation layer that sits between the vendor's status and your credit policy, because that layer is invisible until it is missing.

How should the cutover be sequenced?

Run both in parallel. Do not switch and hope.

Phase 1, shadow mode. Enrol a representative subset in Cobalt monitoring while the existing feed stays live and authoritative. Route the new alerts to a log rather than the queue. Two to four weeks is usually enough to see real behaviour.

Phase 2, reconcile. Compare what each surfaced over the same window. You are looking for changes one caught and the other did not, timing differences between detection and delivery, and any status label your new mapping does not handle. Investigate every discrepancy rather than assuming the new source is wrong; sometimes it is the old one.

Phase 3, cut over the SOS layer only. Move Secretary of State alerts into the live queue and stop routing the old SOS feed. Keep the non-SOS categories running wherever they are running.

Phase 4, decommission deliberately. Retire the old SOS subscription only after the new feed has produced a full cycle of alerts your team has acted on. Confirm what happens to the other four categories in writing before touching that contract.

Two details that cause avoidable pain:

• Deactivate monitors for paid-off accounts on both sides. Middesk's API exposes endpoints to delete a monitor and to bulk disable monitors, which is worth using during migration rather than carrying dead accounts into a new subscription and paying for them twice.

• Do not migrate mid-quarter for cycle-driven fields. Officer and ownership information refreshes on periodic reports, since Texas states there is "no filing requirement with the secretary of state when there is an ownership change" for corporations or LLCs.^[6] Cutting over just before a reporting deadline makes the two feeds look inconsistent when they are simply observing at different moments.

Want to walk through a parallel-run migration against your current monitoring setup? Book a demo.

What should the parallel run actually measure?

Reconciliation done casually produces false confidence, so define the comparison before starting.

• Coverage. Which borrowers produced an alert from each feed. Non-overlap is the finding that matters most.

• Latency from state filing, not from alert. The state's own effective date is in the record. Measure both feeds against that, because time from filing to lender action is the number your clocks care about.

• Status label handling. Every distinct status string each feed returned, and whether your mapping handled it. Unmapped labels are the most common cutover defect.

• Noise profile. How many alerts each produced that resolved to nothing, particularly registered agent mass-updates where a commercial agent relocating moves many unrelated borrowers at once.

• Missed-change checks. Pick borrowers you know changed and confirm both feeds caught them. Absence of alerts is not evidence of absence of change.

Keep the parallel run long enough to span at least one periodic reporting deadline in your main states. A two-week run that never crosses a filing deadline tells you very little about the cycle-driven fields.

What breaks when teams skip the parallel run?

Parallel running is the step most often cut for schedule reasons, and the failures it prevents are all quiet ones.

Unmapped status labels fail silently. State vocabularies vary, and a mapping table built against one vendor's normalization will encounter strings the new feed returns that it has never seen. A well-written handler logs and skips them. A typical handler treats an unrecognized status as no change. Either way the borrower does not reach the queue, and nothing in the system reports a problem, because from the code's perspective nothing happened.

Volume changes are mistaken for risk changes. Severity classification and suppression differ between vendors, so alert counts shift after cutover for reasons that have nothing to do with borrowers. A team seeing volume drop reads it as a quieter portfolio. A team seeing it rise reads it as deterioration. Without a parallel window establishing the baseline, neither interpretation can be checked.

Coverage gaps appear at the edges. Neither vendor publishes a state coverage list specific to monitoring, and coverage for point-in-time lookup is not necessarily the same set. If some fraction of borrowers cannot be monitored under the new integration, that surfaces during a parallel run as non-overlap. After cutover it surfaces as those borrowers simply never generating alerts, which is indistinguishable from them being stable.

Timing differences look like missed changes. A pull model on a 30-day interval and a push model detecting sooner will legitimately report the same change on different dates. Seen side by side that is a latency measurement. Seen after cutover it reads as the new feed having missed something.

The common thread is that every one of these failures produces silence rather than an error. Monitoring systems fail quietly by nature, since their normal output for a healthy portfolio is nothing at all. That is precisely why the migration needs a period where two sources can be compared against each other, and why "we will watch it closely for a few weeks after cutover" is not a substitute. Watching closely tells you what the new feed produced. It cannot tell you what it should have produced.

What does the migration cost in effort and calendar time?

Estimating this badly is the other common failure, usually because the estimate covers the integration and not the interpretation layer.

The engineering work splits roughly into three parts. The API integration itself is small: authentication, a scheduled job, and storing the prior record for comparison. The field mapping is moderate and mostly mechanical, with the caveat that status normalization has to be re-derived rather than ported. The interpretation and routing layer is the largest piece, and if it already exists it mostly survives, because it should be keyed to your internal risk taxonomy rather than to any vendor's field names.

That last point is the one worth designing for even if you never migrate again. A monitoring integration that maps vendor output into an internal taxonomy immediately, and does all downstream routing against that taxonomy, makes any future vendor change a mapping exercise. One that lets vendor field names propagate into ticketing, reporting, and credit policy makes every vendor change a rewrite.

On calendar time, the binding constraint is not engineering. It is the parallel run, which needs to span at least one periodic reporting deadline in your main states to exercise the cycle-driven fields. That sets a realistic floor measured in weeks regardless of how quickly the code is written.

Three groups need to be involved and are often brought in late:

• Credit or portfolio operations, because they own the triage thresholds that will need recalibrating and they will notice volume changes first.

• Compliance, because the four non-Secretary-of-State categories are usually theirs, and a documented decision about what happens to watchlist and bankruptcy monitoring belongs to them rather than to engineering.

• Whoever owns the vendor contract, because decommissioning timing should follow the parallel run rather than a renewal date, and those two calendars rarely align by accident.

Why bother migrating at all?

Worth answering honestly, because for many lenders the answer is that they should not.

The cases where moving the SOS layer makes sense:

• The other four categories are already covered elsewhere. Then a bundle is duplication, and duplicate alerts cost review time even when the data cost is small.

• You need a specified, contractual check interval. Cobalt publishes a configurable 1 to 30 day cadence. Middesk's published documentation describes event-driven webhooks without stating a check frequency, so a cadence commitment there is a procurement conversation.

• You need dated audit evidence. Cobalt's live Secretary of State lookups can return a timestamped, watermarked screenshot of the state website. That is a different artifact from a source URL, and the difference matters where reinstatement and reliance are in play.

• Cost transparency matters for planning. A published per-check credit cost makes a monitoring budget a multiplication rather than a negotiation.

The cases where you should stay put: you rely on watchlist, bankruptcy or lien monitoring from the same vendor, you want one contract, or your webhook infrastructure already exists and works. None of those are bad reasons.

For a category-by-category view of what each product alerts on, see our monitoring comparison, and for the broader product surface our provider comparison.^[7] For why check frequency matters to secured lenders, the four-month UCC amendment window is the binding constraint,^[8] it runs from the change rather than from notification,^[9] and our guide to entity status transitions covers what the alerts mean once they arrive.^[10]