The iOS Home Screen widget’s Safe to Spend summary
const url = 'https://api.tovarifinancial.com/widget/summary';const options = {method: 'GET'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://api.tovarifinancial.com/widget/summaryKAN-3607. NOT a Cognito route: the bearer is a WIDGET KEY (Authorization: Bearer tvw_…, from POST /widget/credentials), resolved by its SHA-256, after which the app’s own verification, policy and subscription gates run as that member. Every money field is SIGNED INTEGER CENTS. Answers { kind: "no_accounts" } when no account is included in Safe to Spend. The figure is the one GET /dashboard/safe-to-spend serves for the same household and local date (“today” is the X-Client-Timezone header, else the zone stored with the key, else UTC). No refusal carries any financial field.
Responses
Section titled “Responses”The widget payload
object
object
object
Integer minor units (cents)
Floored per-day cents; null when the line must not render.
Calendar date, ‘YYYY-MM-DD’
The magnitude below $0, else 0.
object
object
${billId}|${dueDate}
Calendar date, ‘YYYY-MM-DD’
Integer minor units (cents)
Every bill in the window, not just the (at most three) items.
Across all count bills.
Month, ‘YYYY-MM’
object
Integer minor units (cents)
Integer minor units (cents)
Integer minor units (cents)
Example
{ "data": { "kind": "no_accounts" }}WIDGET_CREDENTIAL_INVALID — a missing, malformed, unknown, revoked or expired key, or a removed member (one indistinguishable answer)
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Authenticated, but the tenant gate refuses the request until the caller resolves a precondition. errorCode is one of EMAIL_NOT_VERIFIED, POLICY_ACCEPTANCE_REQUIRED, or SUBSCRIPTION_REQUIRED, evaluated in exactly that order (contract term CCR-1: email verification first, then policy acceptance, then subscription — so a subscriber who has merely not re-accepted the current policies always sees POLICY_ACCEPTANCE_REQUIRED). A POLICY_ACCEPTANCE_REQUIRED body additionally carries details.outstanding (the policy versions still to accept) and details.firstAcceptance. The SUBSCRIPTION_REQUIRED arm is INERT unless the server-side BILLING_ENABLED flag is exactly the string true; while it is off, only the first two codes are reachable. Not retryable as sent — resolve the named condition, then resend.
object
Which precondition refused the request. Evaluated in this order (CCR-1); SUBSCRIPTION_REQUIRED is unreachable while BILLING_ENABLED is not exactly true.
object
Active policy versions the user has not yet accepted.
object
True when the user has accepted no policy before — the client renders the new-signup screen rather than the re-acceptance one.
Example
{ "errorCode": "EMAIL_NOT_VERIFIED"}Internal error (no internal detail leaked)
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}Service temporarily unavailable — errorCode is SERVICE_UNAVAILABLE. A TRANSIENT, RETRYABLE condition rather than a defect in the request: a query that exceeded its time budget, a lost or refused database connection, a saturated connection pool, or an outage at an upstream provider the request depends on (the authentication provider, or the bank data provider on a bank-connection operation). The identical request may succeed on retry — back off briefly and, on a write, resend the same X-Idempotency-Key where the operation accepts one.
object
Machine-readable error code (AUTH_ERROR_CODES).
Optional field-level validation errors, keyed by field name.
object
Example
{ "errorCode": "INVALID_EMAIL_FORMAT"}