A valid request URL is required to generate request examples{
"email": {
"available": true
},
"sms": {
"available": false,
"reason": "disabled"
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123,
"fieldErrors": [
{
"field": "<string>",
"message": "<string>"
}
]
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}Get per-channel notification availability
Reports whether e-mail and SMS may be used for a transactional send right now, folding the network settings, the credit wallet and the current-period usage meter into one verdict. ALWAYS call this before sendSaleReceipt — it is the only free way to learn that a send would be refused, and the caller holding pos.notification.send cannot read the wallet or the settings directly. Each channel returns available, plus a typed reason when it is false: disabled (the channel.sms.enabled network flag is off), insufficient-credits (the wallet cannot cover one SMS) or email-quota-exceeded (the account reached its plan’s monthly e-mail fair-use cap). E-mail is fair-use and never costs credits; SMS is metered. This is a point-in-time snapshot of a shared budget — available: true is not a reservation, so a send can still be refused a moment later.
A valid request URL is required to generate request examples{
"email": {
"available": true
},
"sms": {
"available": false,
"reason": "disabled"
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123,
"fieldErrors": [
{
"field": "<string>",
"message": "<string>"
}
]
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}Authorizations
Authorization: Bearer <token>. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same pos.* scope vocabulary the route guards enforce.