Operations field note

August 2026 product note: clearer checks and safer delivery

This month's work is mostly about refusing silent success: a license lookup that did not answer, a webhook nobody can authenticate, and a text sent without current consent should all fail explicitly at their enforcement boundary.

Sealinn's scheduled worker now stores source-specific license status for three official datasets, outbound webhook deliveries are signed, and number-matched consent plus STOP suppression are rechecked immediately before real SMS delivery. The license-check fields are not yet exposed in the customer UI.

Key takeaways

The license-check worker preserves each source's limits. Washington, Oregon, and Texas do not publish the same fields, so the adapters do not classify their answers as if they were interchangeable. The customer-facing display is not complete yet.
Outbound webhooks carry an HMAC signature and timestamp. A receiver can verify that a delivery came from the endpoint secret it was given and reject stale replays.
SMS has a final delivery gate. Current consent must match the number being texted, and a STOP suppression is checked again immediately before the provider call.
These controls are boundaries, not compliance guarantees. Configuration, review, state rules, provider registration, and the customer's own obligations still matter.

By the Sealinn team · 4 min read · Published August 22, 2026 · Written for general contractors and operations leads evaluating Sealinn

Editorial note: Claims were checked against the license worker, storage schema, product UI, webhook tests, and final SMS transport gate. The license-check fields are not yet customer-facing. This dated implementation note is not a legal guarantee.

The license-check worker stores the result and named source

Sealinn's scheduled worker can query official public datasets for Washington contractor registration, Oregon Construction Contractors Board licenses, and Texas Department of Licensing and Regulation licenses. For a supported row, it stores which source answered, the result, and the time of the attempt. The adapter's source-specific explanation is transient and is not persisted. Current product screens do not display these automated-check fields, so this is an implementation boundary rather than a customer clearance screen. The three sources are deliberately not flattened into one claim: Washington publishes an explicit status, Oregon's dataset is active-only, and Texas publishes an expiry without a status column. The design note on unavailable results explains the failure classifications.

Washington results describe contractor registration and can carry the dataset's own status word.
Oregon results say whether a number appears in the active-license file; an absence does not invent the reason.
Texas TDLR results use the published expiry date and identify the license type; the dataset does not include plumbing licenses or an explicit status field.
During a supported check, network failures, rate limits, and unreadable decisive fields return unavailable rather than active. Unsupported states are skipped by the scheduled sweep.

Outbound webhooks are signed and replay-bounded

A webhook about an approved, rejected, or expiring document can trigger work in another system. That makes authenticity part of the feature, not an optional extra. Each outbound delivery now carries a timestamped HMAC-SHA256 signature computed from the timestamp and the raw request body with the endpoint's secret. Receivers can recompute it with a constant-time comparison and reject a stale timestamp. The exact header and verification recipe are documented in Webhooks and Zapier.

A signed delivery still needs a careful receiver

Verify the signature before parsing or acting on the event, enforce a narrow timestamp window, keep the signing secret out of logs, make processing idempotent, and return a non-success response when verification fails. A signature authenticates the payload; it does not make the receiving workflow safe by itself.

A visitor can submit a text-reminder preference through a subcontractor record's bearer upload page. That link does not verify the submitter's identity or ownership of the number. The preference is stored with the normalized phone number so replacing a contact number does not transfer the old choice to somebody else. Immediately before the real Twilio call, Sealinn rereads the record and the global SMS suppression list. No current number-matched preference, or a recorded STOP, blocks the provider call for scheduled and staff-triggered reminders alike. The public messaging program terms now describe that same behavior.

Moment	Check	Why it is not enough on its own
Upload-page preference	The bearer-link holder submits a choice and exact number	The link verifies neither identity nor phone ownership, and the saved state can change later
Message creation	The workflow has a permitted reminder to send	A queued message may wait while the recipient opts out
Provider boundary	Consent still matches the destination and STOP is not active	Provider registration, carrier rules, delivery, and content obligations still apply

The final gate is intentionally later than the button click or queued job.

Why these changes ship together

They share one rule: do not convert missing evidence into success. During a supported license check, an endpoint that did not answer produces unavailable. A webhook whose receiver cannot authenticate it should be rejected. A text without current consent should not reach the transport. The stored result may be less convenient than an always-green default, but it is more accurate. The current license-check fields still need a customer-facing display; human review remains part of the product, and security claims are published with their limits.

How to test the release yourself

For license status, keep using the issuing authority's own lookup. The current product UI does not provide a way to inspect the worker's stored source, result, attempt time, or transient adapter detail.
Create a webhook endpoint, copy the signing secret once, and verify a test delivery using the documented raw-body procedure.
Use a phone number you control, submit a preference through a test record's bearer upload page, send a controlled reminder, then reply STOP and confirm the next send is blocked.
Export the resulting records and review the audit history so the evidence survives outside the screen where the action occurred.

Release boundaries

Do license checks now cover every state and trade?

No. The scheduled worker selects only the documented Washington, Oregon, and Texas datasets, and each has scope limits. Unsupported states are skipped rather than assigned a customer-visible result. The automated-check fields are not yet displayed in the product, and classification and job-scope review remain human work.

Does SMS consent make every message legally compliant?

No. The product gate prevents a send without current number-matched consent or after STOP, but customers still need an appropriate use case, accurate records, registered sending infrastructure where required, and legal advice for their jurisdiction and program.

Are inbound provider webhooks also verified?

Stripe, Clerk, Resend, and Twilio inbound routes each use the provider's signature scheme and reject failed verification when configured for real service. The outbound webhook described here uses Sealinn's endpoint secret and documented HMAC format.

Where this comes from

Washington State Department of Labor & Industries — Contractor License Data
Oregon Construction Contractors Board — Active CCB Licenses
Texas Department of Licensing and Regulation — TDLR All Licenses
Twilio — Twilio Messaging Policy

Inspect the controls with your own records.

Start free, test one workflow at a time, and keep the evidence if you decide to leave.

Start free