Reapit · OAuth Scopes
Reapit OAuth Scopes
OAuth 2.0
searched
Reapit uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.
This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.
Real EstateUnited KingdomPropTechCRMEstate AgentsProperty ListingsProperty ManagementRentalsConveyancingAustralia
Scopes: 0
Flows:
Method: searched
Scopes (0)
Reapit implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.
📄 Provider scope reference: https://foundations-documentation.reapit.cloud/platform-glossary/permissions
Source
OAuth Scopes
generated: '2026-07-26'
method: searched
source: >-
https://foundations-documentation.reapit.cloud/api/webhooks (the topic table
publishes the literal scope string required for each event),
https://foundations-documentation.reapit.cloud/platform-glossary/permissions
(the human-readable permission domains),
https://foundations-documentation.reapit.cloud/api/mcp-alpha ,
https://foundations-documentation.reapit.cloud/api/notifications , and the
live Reapit Connect OIDC discovery document at
https://connect.reapit.cloud/.well-known/openid-configuration
docs: https://foundations-documentation.reapit.cloud/platform-glossary/permissions
description: >-
Reapit's permission model is two-layered and unusual. Reapit Connect is an
Auth0-backed OpenID Connect tenant whose discovery document advertises only
the standard OIDC profile scopes; the Foundations platform scopes are
application permissions selected at app registration in the developer portal
and then granted PER CUSTOMER at install time, so they never appear in the
anonymous discovery document. Reapit does not publish a single canonical scope
reference page — the permissions glossary lists the domains in prose, while
the webhook topic table is the one place that publishes literal scope strings.
The platform scopes below are therefore the ones Reapit states verbatim in the
documentation; the wider set follows the same
<resource>.read / <resource>.write shape but each unlisted write scope is
marked evidence: inferred rather than asserted as published.
model:
granted_at: customer install time (AppMarket), not at token issuance
selected_at: app registration in the developer portal
change_process: >-
Adding a permission requires contacting the Reapit Partnerships team
(partners@reapit.com) with the business purpose, then creating an app
revision; EVERY customer who has installed the app must individually accept
the new permission by email before Reapit approves the revision.
revocation: uninstalling the app revokes all access to that customer's data
insufficient_scope: 403 Forbidden
identity_scopes:
source: https://connect.reapit.cloud/.well-known/openid-configuration
supported:
- openid
- profile
- offline_access
- name
- given_name
- family_name
- nickname
- email
- email_verified
- picture
- created_at
- identities
- phone
- address
platform_scopes:
- scope: agencyCloud/mcp.access
description: >-
Required on the Reapit Connect JWT to call the Foundations MCP server. A
token without it is rejected with 403.
evidence: published — https://foundations-documentation.reapit.cloud/api/mcp-alpha
- scope: applicants.read
description: Read applicants; required for applicants.created / applicants.modified webhooks.
evidence: published — webhook topic table
- scope: appointments.read
description: >-
Read diary appointments; required for appointments.created / .modified /
.cancelled / .confirmed webhooks.
evidence: published — webhook topic table
- scope: companies.read
description: Read companies; required for companies.created / companies.modified webhooks.
evidence: published — webhook topic table
- scope: contacts.read
description: >-
Read contacts; required for contacts.created / .modified / .optedout /
.landlorddetails.updated webhooks.
evidence: published — webhook topic table
- scope: conveyancing.read
description: Read conveyancing (sales progression); required for conveyancing.modified webhooks.
evidence: published — webhook topic table
- scope: documents.read
description: Read documents; required for documents.created / documents.modified webhooks.
evidence: published — webhook topic table
- scope: enquiries.read
description: >-
Read enquiries (internet registrations); required for enquiries.created /
.modified / .accepted / .rejected webhooks.
evidence: published — webhook topic table
- scope: identitychecks.read
description: >-
Read AML/KYC identity checks; required for identitychecks.created /
identitychecks.modified webhooks.
evidence: published — webhook topic table
- scope: landlords.read
description: Read landlords; required for landlords.created / landlords.modified webhooks.
evidence: published — webhook topic table
- scope: negotiators.read
description: >-
Read negotiators. Required to call POST /notifications, because an app must
map its own users back to Reapit negotiator ids to target a notification.
evidence: published — https://foundations-documentation.reapit.cloud/api/notifications
- scope: offers.read
description: >-
Read offers; required for offers.created / .modified / .accepted /
.rejected / .withdrawn webhooks.
evidence: published — webhook topic table
- scope: offices.read
description: Read offices; required for offices.created / offices.modified webhooks.
evidence: published — webhook topic table
- scope: properties.read
description: >-
Read properties and property images; required for properties.created /
.modified, all properties.selling.* topics, and propertyimages.* topics.
evidence: published — webhook topic table
- scope: referrals.read
description: Read referrals; required for referrals.created / referrals.modified webhooks.
evidence: published — webhook topic table
- scope: tenancies.read
description: Read tenancies; required for tenancies.created webhooks.
evidence: published — webhook topic table
- scope: tenancies.write
description: >-
Write tenancies. Documented as the scope required for the
tenancies.modified webhook — the only .modified topic in the whole table
that demands a write scope rather than a read scope.
evidence: published — webhook topic table
- scope: vendors.read
description: Read vendors; required for vendors.created / vendors.modified webhooks.
evidence: published — webhook topic table
- scope: worksorders.read
description: >-
Read works orders; required for worksorders.raised / .modified / .complete /
.cancelled webhooks.
evidence: published — webhook topic table
permission_domains:
source: https://foundations-documentation.reapit.cloud/platform-glossary/permissions
note: >-
The permissions glossary enumerates the data domains an app can request,
split by the docs into 'Read' (ingest CRM information) and 'Write' (push new
or amended data into the CRM). Literal scope strings are not printed for
every domain; the .read/.write suffix pattern is confirmed by the webhook
table for the domains listed above.
domains:
- applicants
- areas
- appointments
- certificates
- companies
- contacts
- conveyancing
- documents
- enquiries
- identity checks
- invoices
- journal entries
- keys
- landlords
- negotiators
- offers
- offices
- properties
- property alarm data
- referrals
- sources
- tasks
- telephony notifications
- tenancies
- transactions
- vendors
- works orders
gaps:
- No single canonical scope-reference page lists every literal scope string with
its description; the strings must be assembled from the webhook, MCP and
notifications pages.
- The OIDC discovery document does not advertise any platform scope, so an agent
cannot discover the Foundations permission surface from the well-known endpoint.