consent/get-banner reads a single banner configuration by ID.
Name, active, default. Small on purpose.
At a glance
| Ability | consent/get-banner |
| Toolset | CookieYes — toolset/cookieyes |
| Group | CookieYes › The Banner |
| Requires | CookieYes, active on the site |
| Capability | manage_options |
| Safety | Read-only — changes nothing |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
The banner record itself carries very little. Almost everything a visitor sees comes from elsewhere — the categories, the declared cookies, the language list, the settings — and the banner is the configuration that decides how those are put to a visitor under a particular law.
So this is the call that answers “is this the one that is live”, and not much else. For what visitors are actually receiving right now, consent/get-banner-status reads the built output rather than the configuration.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
id | integer | Yes | Banner ID, from consent/list-banners. |
What comes back
| Name | Type | What it is |
|---|---|---|
banner | object | ID, name, active flag and default flag. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Is banner 2 the active one?
It resolves to one call:
{
"ability": "consent/get-banner",
"parameters": {
"id": 2
}
}Worth knowing
- Configuration, not output. Use
consent/get-banner-statusfor what is being served.
Related abilities
- List Consent Banners — find the ID
- Get Banner Status — the built banner
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category