A provider reads records through your API. What may it do?

A worked scope class for a provider that reads records through your API on behalf of a named person, such as a reporting or planning service your staff or your customers use.

Reading is the most common thing a provider does through an API, so the guardrails are about how much, on whose authority, and nothing else.

Everything on this page is illustrative. It is not published as a scope class, it binds nobody, and no member is admitted into it. The real one for your API is written with you.

All example scope classes · Illustrative example · first published 3 September 2026, revised 25 September 2026 · Read with the rulebook

In one minute

The guardrails are short. Reading is allowed, within limits. Everything that changes a record, moves money or contacts someone else is denied.
Every read rests on a named person’s authority. The provider reads on behalf of someone identified, and that authority lasts at most 24 hours.
Both sides report. The provider and your API each send a short signed report for every session and every call. The two are matched.
Every breach is a yes-or-no question. No judgment and no argument about intent.
Rootwall confirms that no guardrail has been broken. The provider has signed for what it did, checks itself first, and owes a sum fixed in advance when a guardrail is broken or the two sides do not match.

Part A

The scope class: the guardrails

Reference SC-READ-1 (illustrative) · a session is one connection by the provider · an interaction is one call to your API

The guardrails

Each action is allowed or denied, and an allowed action may carry a limit. These are control points based on rules. They make sure the provider behaves, or it pays a fixed sum.

Action	Rule	Limit
Read one record`read.record`	Allow	All reads together: up to 600 an hour and 5,000 a day
Read a list or run a search`read.collection`	Allow	Up to 200 an hour, within the total above
Keep sessions open	Allow	Up to 10 at once
Create a record	Deny	—
Change a record	Deny	—
Delete a record	Deny	—
Move money	Deny	—
Send a message to someone else	Deny	—

Every read needs a delegation: the authority of a named person or organization on whose behalf the provider is reading, valid for at most 24 hours. The person is named in the report, and the provider states that it checked the authority.

Limits are counted per provider and count only the calls the provider made. They are set per hour and per day, because a limit per session could be dodged by opening more sessions.

What a scope class can and cannot say

Rootwall never sees what is inside your traffic. Reports carry the names of the fields in a call and a fingerprint of their values, never the values.

In a scope class: which kinds of call are allowed, how many, over what period, on whose authority, and what each side must report.
Not in a scope class: anything that needs a value to be read, such as a maximum field length, a date range, or what may appear in a search. Rootwall could not check it.

Those rules still exist, at your own edge. You may always apply a restriction stricter than the class, privately, without telling anyone. A refusal under that right is not a breach by anybody.

The class names kinds of call, not your endpoints. You map each of your endpoints to a kind, by what it actually does. An endpoint that reads and quietly writes maps to the write.

What each side reports

Both sides report	The provider also reports
Session open, one report for each call, session close	The delegation the session rests on
On every report: the session identifier, who sent it and in which role, the kind of call, who initiated it, and the field names with a fingerprint of their values	The build of the software that made the calls

Deadline: within 15 minutes of the session closing. Reporting is never in the path of your traffic and never a dependency of your service.

What is a breach, and what it costs

#	Breach	Fixed sum
B1	Attempting a denied actionAn attempt counts, whether or not it succeeded	$250per session
B2	Reading without a valid delegationNone, expired, or beyond what the person authorized	$500per session
B3	A session or call you saw, with no report from the providerNever cheaper than B2: silence must not pay	$500per session
B4	A false or misleading reportIncluding a call mapped to a kind that understates what it does	$500per report
B5	A late reportThe common case: a provider that forgot	$50per report
B6	A limit exceeded	$100per hour

Forgetting is cheap. Reading without authority is not.

Sums are paid by the provider to you, never to Rootwall. No single breach costs more than half of a provider’s yearly membership. Aggregate cap: $5,000 per provider, per counterparty, per rolling 30 days. Standing moves too: repeated breaches put a provider under review, and can suspend it. Illustrative figures for this example.

The same API, one step riskier

A class that also allowed creating and changing records would move everything else with it:

Tighter limits on the changes than on the reads, because a wrong change costs more to undo than a wrong read.
A shorter delegation: hours rather than a day.
Higher sums, for the same reason.

What does not change: the rules themselves, the reporting standard, or anything in the rulebook. A scope class sets what a provider may do. It never varies a rule.

How the real one gets written

You list what your API exposes and map each endpoint to a kind. Only you know what your endpoints actually do.
We set the limits together, against what your ordinary traffic looks like.
The sums are set with the class, as a pre-estimate of what each kind of breach would cost you to deal with. You are the party they are paid to.
It is published, and every provider admitted after you is held to it.

The first company in your industry sets the rules, and puts its name on them.