Examples & reference
FAQ
Can I change integration type after creating?
No. Create a new app and archive the old one.
How long is review?
Typically 1-3 business days. Embedded apps take a bit longer.
Can one token serve multiple tenants?
No. Each installation token is bound to exactly one (tenant, app) pair.
The one exception is not a token but a person: your app, open in a complex
or company, reads the schools beneath it with ?entities= — see the next
question.
Can a complex's app read its schools' data from the mini-app?
Yes, with no server endpoint. Name the schools on the same data read:
Okta.getQuery('/api/apps/education/students', {'entities': 'A,B'}) returns
an envelope keyed by school, and {'entity': 'A'} returns one school's answer
as is. Your app must hold entity.hierarchy.read, the data scope must be
granted on the complex or on the school (either is enough), and the person must
hold tenants.children.view_members in the complex. A school that never
installed your app is read with the complex's grant. Each school's key is
either its answer or a refusal carrying error — tell them apart with
identical(answer['error'], null), never == null, which misreads the key an
answer does not carry. The details are in the chapter «Companies and complexes:
the tree and its schools' data», and the example in the native mode chapter.
Can a complex install my app in its schools so they cannot remove it?
Yes — when you opt the app in with {"hierarchy": {"managed_install": true}}.
The complex installs it for itself, chooses its schools, and each school keeps
the app's settings but cannot uninstall it: it reads «installed by hierarchy.managed_install».
Is my app installed in a complex's schools automatically when the complex installs it?
When you choose so: {"hierarchy": {"reach": "container_and_children"}} (the
«The complex and its schools» choice in the version editor). It is then
installed in every entity beneath the complex as a managed copy the moment the
complex installs it, and in every entity that joins it later. Without the key —
or with "container" — it is installed in the complex alone, which is what
every app does today. The details are in «A complex's install covers its
schools — hierarchy.reach».
Can a complex's app write a record in the pupil's own school?
Yes — an embedded app, in process: ActForStudentsInTree for a batch of
pupils, ActInChildEntity for one school; there is no HTTP route for it. The
person holds two keys at the complex — tenants.children.operate_apps and your
app's permission for the act — and only schools whose copy of your app the
complex's own installation manages (hierarchy.managed_install /
hierarchy.reach) open. The platform places each pupil in their school on the
server, runs your code inside that school under the school's own copy, and the
parents' notification goes out under that copy — with the school's settings,
or the complex's until somebody at the school sets that notification. Never
take the school from the request, and never use RunAsChildEntity on a request
path. The details are in «Your app works inside a complex's schools —
ActInChildEntity».
What if a webhook is delayed?
Nothing is lost. Every delivery shows up on the "Webhook Deliveries" page with manual replay.
Where do I add my app's notifications?
See the Notifications catalog section.
Short: Apps → pick your app → "Notifications" tab
(/dashboard/modules/<slug>?tab=notifications).