GET/v1/franchise-report-share
What the brand may see
What this business lets its brand read — whether the brand's reports across its franchisees
may show this business's figures (locations and groups, item 18). A merchant with no brand
is 404: there is nothing to share. The figures themselves are derived on read from this
business's own data, never copied (0119); this answers only the grant.
Responses
-
200
The grant, as it stands.
FranchiseReportShare · application/json
brand_idstring · uuidRequired
The brand this business is a franchisee of, read-only on the merchant (0008).
brand_namestringRequired
How the brand calls itself, for the franchisee's own screens.
sharingbooleanRequired
Whether the brand may read this business's figures (locations and groups, item 18). Nothing is shared until the owner grants it, and the grant is revoked on any of the brand's reports. This answer is what a franchisee's own screens show as "waiting for the owner" until it is set.
versionVersionRequiredRead only
Optimistic concurrency version, raised by the server on every write. A version is never lower than one already returned for the resource, though it may rise by more than one.
Returned in the
ETagresponse header as well as in the body. Send it back inIf-Matchon an update and the write is rejected with412if anyone else has written since — which is what stops two tills silently overwriting each other's edit to the same product when both come back online at once.≥ 1
-
400
The request could not be parsed. Malformed JSON, a bad query parameter, or a header that failed to decode, among them an
API-Versionlater than the server speaks or not a date (api-version-unknown, with the server's own inapi_version).Distinct from
422: a400never reached validation, soinvalid_paramsis absent. Retrying without changing the request will fail again, except that a request refused for itsAPI-Versiongoes once the server is updated. -
401
No credentials, or credentials that could not be verified — missing bearer token, malformed JWT, expired token, or a signature that failed against the issuer's JWKS.
Refresh the token and retry once. Repeated
401after a refresh means the device needs to re-enrol. -
403
Authenticated, but not permitted. The token is valid and its merchant was resolved, but the caller's role does not allow this operation, or the target belongs to a different merchant.
Cross-tenant access is reported as
403on a resource the caller may not see, and as404where even confirming existence would leak information. Retrying will not help. -
404
No such resource, or none visible to this caller.
Also returned instead of
403where acknowledging existence would itself leak information — so a404does not prove the id is unused globally, only that it is not yours. -
410
The request names an
API-Versionthis server no longer serves (docs/decisions/0011). Nothing in it was read.api_versionnames the version the server speaks: the client is behind, and sends the request again once it is updated. -
429
Rate limit exceeded. Honour
Retry-Afterrather than applying your own backoff.A fleet of tills coming back online together after an outage is the realistic cause, which is exactly when uncoordinated client-side retry turns a brief outage into a sustained one. The limit is per process, and per site for what records trade there — a request spends its site's budget, and a till's own smaller one inside it — and per
(client, merchant)for everything else; noRateLimitfield is sent, so this response and itsRetry-Afterare the whole of the contract. -
500
Something failed on our side.
trace_ididentifies the request in our tracing — quote it in a support ticket.The body never carries internal detail: no SQL, no stack traces, no upstream error strings. Safe to retry with the same
Idempotency-Key. -
503
Temporarily unable to serve the request — a dependency is down or the service is shedding load.
Retry with the same
Idempotency-KeyafterRetry-After. This is always safe: a request that did take effect before the failure will be recognised as a replay.