Show what the account can do and what it is missing
Start here before configuring anything. Answers, in one call: which channels exist, which are switched on for this installation, which the plan permits, which the company has already credentialed, and who can be reached right now.
Without it you would be guessing. Adding a Viber contact to a company that never configured Viber succeeds — and then alerts vanish silently, because nothing on the create path knows the channel cannot deliver.
How to use the answer:
- Read top-level blockers first. They mean nothing is delivered at all; per-channel fixes will not help until they clear.
- Pick channels with status ready (work now) or needs_setup (worth proposing). Skip disabled entirely — an operator switched those off and the customer cannot change it. Mention plan_blocked only if suggesting an upgrade. status is one verdict shared with the other two state surfaces: GET /recipients/{recipient}/availability and the deliverable flag of GET /recipients/{recipient}/routes answer the same question about the same channel, so a channel that is not ready here is never reported as working there. It covers the installation's own transports too — email over an unconfigured mailer reads needs_setup with email_not_configured, not ready, even though there is nothing for the customer to fill in.
- For a needs_setup channel, act on the blocker's remedy. request_credential_link is the common one: POST to the given endpoint, show the returned URL to a human, and poll its status_url until verified. Never ask a human to paste a token to you — it would end up in your context, your transport logs and your conversation history, and cannot be erased from any of them.
- Before promising delivery, check recipients.deliverable. Channels that work with nobody on them deliver nothing.
- Read onboarding_window before deciding how many recipients or groups to create. While it is active the plan caps on those are not applied, so design what the company actually needs instead of squeezing the design into a limit that is not currently in force — and say when it ends.
Secrets are never returned by this endpoint, under any ability. You get whether credentials are set, whether the provider accepted them, and the names of the fields still missing.
Read-only and free of side effects: safe to poll while walking a human through setup. Reflects the state at the moment of the call — re-read it after any change rather than caching.
Request
- Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
- URL: https://wardenpoint.com/api/v1/capabilities
- Auth: API key in header X-API-Key
Response
The account's capabilities and everything currently standing in the way.
Example response
{
"data": {
"onboarding_window": {
"lifted_limits": [
"max_recipients",
"max_groups",
"max_members",
"max_api_keys",
"max_outbound_webhooks",
"max_alert_templates",
"max_notifications_daily",
"max_notifications_monthly"
]
}
}
}Changes
No recorded changes to this operation across all 1 revision of this API.