Executive Summary: Yes. Middesk's monitoring product sends webhook events when a monitored business's Secretary of State registration changes, and registration status is one of the fields covered. Their documentation instructs developers to subscribe to `registration.created` and `registration.updated` and use those events to "detect a change to any field on an existing registration."[1] The more useful questions are what has to be built around that event, what it does not cover, and how it compares to the alternatives.
How does the Middesk status alert actually work?
It is a push model built on webhooks rather than a report you pull.
A business is enrolled in monitoring, and thereafter Middesk sends events to an endpoint you host. For Secretary of State changes their documentation describes "granular events that make it easy to subscribe to specific types of changes associated with a business's SOS registrations," covering "changes to the name, people, addresses, or registrations associated with the monitored business."[2]
The published event list for SOS monitoring:
• `registration.created` and `registration.updated`, for new registrations and changes to existing ones.[2]
• `name.created` and `name.deleted`, when a business or DBA name is added or removed.[2]
• `person.created` and `person.deleted`, when an individual's name is added or removed from a registration.[2]
• `address.created` and `address.deleted`, for address changes on a registration.[2]
• `monitor.created` and `monitor.updated`, for the enrollment record itself.[2]
Status specifically arrives inside `registration.updated`. There is no dedicated status event; the pattern is to receive the update and inspect which field moved. Their sample payload carries `status`, `sub_status`, and `status_details` fields alongside `previous_attributes`, so the delta is delivered rather than reconstructed on your side.[1]
That design has a real advantage worth naming: you are told what the previous value was. A pull-based check has to store the prior record to know that anything changed at all.
What do you still have to build?
The event is the start of the workflow, not the workflow. Four things sit on your side regardless of vendor.
A webhook endpoint with real operational commitments. Signature verification, retry handling, idempotency, and availability, because a delivery you fail to accept is an alert you never received. This is ordinary engineering, and it is not zero.
Field-level interpretation. `registration.updated` fires for a change to any field. Distinguishing a status move from an address correction means reading `previous_attributes` and deciding which fields matter to you. The granular name, person, and address events help, but status shares an event with everything else on the registration.
Severity and routing. Nothing in the event says how urgent it is. A status change to administratively dissolved and a formatting correction to a suite number arrive through the same channel and need different responses.
Status translation. This is the one most teams underestimate. State terminology is not standardized: "not in good standing," "delinquent," "administratively dissolved," and "revoked" mean different things in different states, and the sample payload's `status`, `sub_status` and `status_details` fields reflect that variability rather than resolving it. Our guide to entity status transitions covers what each label costs a lender.[3]
Receiving the event is the easy part. Deciding that this particular status, in this particular state, on this particular borrower, warrants a phone call today is the part that determines whether monitoring produces action.
What does Middesk monitoring cover beyond status?
More than Secretary of State data, and this is where their product is genuinely broad.
Their documentation describes monitoring across Secretary of State registrations, TIN registrations, watchlist hits, bankruptcies, and UCC liens, noting that enrolled businesses are tracked for "important changes like bankruptcy filings, registration updates, and lien activity."[4] Lien monitoring is described as tracking "new and terminated UCC liens for subscribed businesses."[5]
For a lender evaluating a single vendor to cover several categories at once, that breadth is the strongest argument in their favour, and it is worth weighing honestly against whatever those categories currently cost you separately.
The weighing needs to be done against your actual stack rather than in the abstract, because breadth only pays where you lack coverage. A lender already screening sanctions through a compliance platform, already pulling UCC data on a schedule, and already receiving bankruptcy notifications gains one new capability from a five-category bundle, not five. The other four arrive as parallel alert streams duplicating systems already running, and duplicate alerts consume the same review time as genuine ones while quietly reducing confidence in the queue.
Run the categories as a checklist instead. For each of Secretary of State, TIN, watchlists, bankruptcy, and liens, mark whether you currently have coverage and whether that coverage runs on an interval you are satisfied with. Rows where the answer is no are genuine gaps worth paying to close. Rows where the answer is yes are rows where consolidation may still be worth it for vendor-management reasons, but it is not buying you protection you did not have.
There is a structural point underneath this too. The four categories outside Secretary of State data are not a roadmap gap in a Secretary of State monitoring product; they are permanently out of reach of one, because the underlying records live in different systems entirely. Bankruptcy filings sit with federal courts, UCC filings with state filing offices under a different regime, and sanctions data with Treasury. A product that re-reads a Secretary of State record will never surface them no matter how often it runs. Planning around that boundary rather than expecting it to move is the correct posture for a buyer.
How does Cobalt's approach differ?
Narrower in scope, and more specified in how it runs.
Cobalt's Business Monitoring, launched July 31, 2026, re-checks the Secretary of State record on a schedule you configure from 1 to 30 days and reports what changed against the previous check, with changes classified by severity across the record's field categories. Each completed check costs 1 credit from the same shared pool as the rest of the API suite.[6]
Its scope is the Secretary of State record only. It does not monitor watchlists, bankruptcies, UCC filings, court records, or licenses, and Cobalt's own OFAC documentation was updated to state that Business Monitoring does not close the sanctions re-screening gap.
The differences that actually bear on a status-change workflow:
• Severity classification is supplied rather than built. Cobalt classifies changes before delivery; Middesk's model gives you granular events and leaves the severity model to you. Which is better depends on whether your team wants to own that logic.
• Cadence is published. Cobalt documents a 1 to 30 day configurable interval. Middesk's published documentation describes event-driven webhooks and does not state a check frequency, so a specific cadence commitment is a question for their sales team rather than something a buyer can read.
• Cost model is published. Cobalt states a per-check credit cost. Middesk gates monitoring access behind sales contact without published pricing.
• Pull versus push. Cobalt's model is a scheduled check you initiate. Middesk's is an event they send. Push requires webhook infrastructure; pull requires a scheduler and stored prior state.
None of that makes either product better. It makes them different purchases, and the right one depends on what your stack already covers.
Want to see how configurable Secretary of State change detection compares against your current setup? Book a demo.
What does handling a status alert look like in code?
Middesk's documented pattern is to receive the registration event and inspect `previous_attributes` to determine which field moved. Their published example follows this shape:[1]
@app.route('/monitoring_webhook', methods=['POST'])
def monitoring_webhook():
event = request.get_json()
if event['type'] == 'registration.updated':
reg = event['data']['object']
changed = reg.get('previous_attributes', {})
if 'status' in changed:
handle_status_change(
business_id=reg['business_id'],
old_status=changed['status'],
new_status=reg['status'],
state=reg['state'],
)
return '', 200That handler is roughly ten lines and it is the part that gets estimated. The parts that do not get estimated are where the effort actually goes.
`handle_status_change` is where the work is. It has to map a state-specific label to your own risk taxonomy, decide whether this particular transition matters, look up current exposure for the borrower, and route to a person with the authority to act. None of that is supplied by the event, and all of it is specific to your credit policy.
The same event fires for changes you do not care about. `registration.updated` covers any field on the registration, so the handler above silently ignores address corrections, formatting normalizations, and file number changes. That is correct behaviour and it means the volume reaching your endpoint is higher than the volume reaching your queue, which is worth knowing when sizing the endpoint.
Idempotency is not optional. Webhook systems retry. A handler that opens a ticket every time it receives an event will open several for one change, and duplicate tickets on a status alert are worse than usual because they look like multiple borrowers in trouble.
Registered agent mass-updates will land here. When a commercial registered agent relocates, it updates the registered office across every entity it represents. Those arrive as legitimate address changes on many unrelated borrowers in one window. Filtering that pattern requires seeing your whole portfolio, not one event at a time, and it is the single largest source of noise in this category regardless of vendor.
A pull-based model puts the same logic in a scheduled job instead of an endpoint. The comparison work is explicit rather than delivered, and you own the timing:
curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=TX" \
-H "x-api-key: YOUR_API_KEY"Neither shape is meaningfully harder. The realistic estimate for either is dominated by the interpretation and routing layer, which is identical in both cases and which is usually left out of the build estimate entirely.
Why does the speed of a status alert matter?
Because for secured lenders there is a clock running that is shorter than most monitoring intervals, and it is attached to a field neither vendor treats as special.
If a debtor's name changes so a filed financing statement becomes seriously misleading, the filing perfects collateral acquired "before, or within four months after" the change and stops perfecting later acquisitions unless an amendment is filed inside that window.[7] The clock runs from the change itself, not from the date you were notified, and catching it is the secured party's responsibility rather than the debtor's.[8]
Both products detect name changes. Middesk exposes `name.created` and `name.deleted` explicitly.[2] Cobalt tracks names as a field category. What determines whether you act in time is the interval between checks plus the delay in your own queue, and the second number is usually larger than the first.
That is the practical reason to ask any vendor in this category for a maximum interval rather than a typical one, and to measure your own time from state filing to lender action rather than time from alert to acknowledgment.
What will no status alert ever tell you?
Three limits apply to both products and to any competitor, because they are properties of the public record rather than of any vendor.
• Ownership changes are not filed. Texas states directly that "there is no filing requirement with the secretary of state when there is an ownership change" for corporations or LLCs.[9] Officer and people monitoring surfaces governance changes on the next periodic report, not equity transfers as they happen. The March 2025 FinCEN rule exempting US-formed entities from beneficial ownership reporting means no federal registry fills that gap either.
• Cause is never in the event. A status change to dissolved does not say whether the trigger was a forgotten annual report or genuine distress. Most administrative dissolutions have mundane causes and are curable, which is why treating every status alert as a default event destroys performing relationships.
• Nothing tells you your reinstatement window. That is statutory and varies sharply: Texas allows reinstatement at any time but backdates it only within three years, Florida permits application at any time, and Georgia caps it at five years. Our guide to the administrative dissolution reinstatement window covers how those clocks differ.
What should a buyer do with this?
Four steps, and the first one is not a vendor question.
Decide which categories you actually need monitored. If sanctions, bankruptcy and liens are already covered elsewhere, breadth is duplication rather than protection. If they are not, a single-category product will not close those gaps.
Ask for a maximum check interval in writing. Not a typical one. For secured exposure the answer needs to be comfortably shorter than four months, and it is a procurement question with either vendor.
Plan the triage layer before the integration. Both products deliver changes and neither decides who reviews them. Detection feeding an unread queue costs money and delivers nothing.
Test the status translation on your own states. Take ten borrowers across the states you actually lend in, look at what each vendor returns for status, and check whether your workflow can act on it without a human interpreting the label. That test is more informative than any feature comparison.
For the broader vendor picture, our Cobalt and Middesk provider comparison covers the full product surface, and the monitoring-specific comparison sets out what each product alerts on category by category.[10]
.jpg){kind=small}
.png)