Maintain a database table of verified businesses with columns: middesk_id, ein, legal_name, last_verified_at, and recheck_due_at (set to 90 or 180 days from last_verified_at)
Run a daily job querying records where recheck_due_at <= NOW(); for each, POST https://api.middesk.com/v1/businesses with the same fields as the original verification order
Compare the new business.id result's registration.status and watchlist.hit values against the stored baseline; generate a change report if either differs
If an EIN mismatch is returned (Middesk resolves a different TIN for the same legal name and address), flag for compliance escalation
Update last_verified_at and recheck_due_at in your database on successful webhook resolution; set next recheck to your configured interval
For high-risk counterparties, enable Middesk's monitoring product (POST /v1/businesses/{id}/monitoring) to receive push alerts between scheduled re-orders
Known gotchas
Each new POST to /v1/businesses creates a separate Business object and incurs API usage costs; if your plan bills per verification, scheduled re-orders at scale can be expensive — consider using monitoring webhooks for active entities instead
Middesk does not deduplicate businesses by EIN; if you re-submit the same entity multiple times you will accumulate multiple Business objects — use your stored middesk_id to re-fetch the existing object rather than creating a new one unless you specifically want a fresh verification run
SOS data staleness means a 'clean' re-verification today does not guarantee the entity will remain in good standing tomorrow; use monitoring in addition to periodic re-orders for critical counterparties
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp