Check send readiness

Find out whether this workspace can actually send yet, and what is standing in the way, as branchable data rather than a failed send.

Channels belong to a business, so readiness is answered per business. Pass ?business_id= to ask about one of your customers; a key already narrowed to a business answers for that business automatically. scope.business_id in the response says which. If it is null, the answer covers the whole organization and is not about any single customer.

Most integrations stall on provisioning, not code: a WhatsApp Business Account has to be connected and a wallet funded, and both need a human at the customer's business. This endpoint turns that from a support question into something your code can read.

There are two answers because the send gate has two floors. can_send is for a TRANSACTIONAL send (what you get when you do not set message_type) and can_send_marketing is for a marketing one, which is stricter: an empty wallet still lets transactional messages out on a small grace allowance while marketing is refused at zero. Read the field that matches the send you are about to make. WhatsApp is never wallet-blocked either way; it bills direct between the business and Meta.

Every blocker carries a stable code, the channels it blocks, the message types it blocks on those channels (blocks_message_types), and how it is resolved. resolve: dashboard means a person must act: surface it to your user rather than retrying. meta_review means wait and poll.

A blu_test_ key always reports ready with an empty blockers list: the sandbox simulates every provider, bills nothing, and needs no connected channel. What a live key would still be waiting on is returned as pending_for_live, so you can show your customer their remaining setup while you build.

Read-only and cheap, with no provider calls. Safe to poll while waiting on a human step.