Enhanced Filing Blocker Management

We’re excited to announce new filing blocker management endpoints. You can now manage filing blockers via API, eliminating the dependency on Zendesk tickets for updating the majority of blocker types.

1. POST /filings/{id}/add_blockers with the blocker_type as an array in the body will place a blocker on a filing. In production, only held_by_customer is accepted. In sandbox, other issue types are accepted for testing.
2. POST /filings/{id}/remove_blockers with blocker_type as an array in the body will remove a blocker and return the filing to a pending status if all blockers are removed. Multiple types can be specified in a single request. Some blockers cannot be manually removed and the endpoint will return a descriptive error explaining why. Read more in our API Guide.

A few reminders to keep in mind:

1. We will automatically queue pending filings for refile if the filing is closed. Each refile attempt will count as a delayed_filing for billing, so ensure the underlying issue is resolved before removing the blockers.
2. The status_history value in the filing object is updated to include all of the blockers in the blocked_reason array. It previously only returned the most recently added blocked_reason.
3. This release replaces the API call to hold a filing that was previously announced. The add_blockers and remove_blockers APIs will take the place of the POST /filings/{id}/hold and POST /filings/{id}/release_hold that was previously proposed. The updated status_history functionality will replace the proposal for hold_history.

These changes are live today in Sandbox and Production.