Submit for approval
What to have ready before you submit, what a reviewer looks at, and what changes when an app is approved, sent back or disabled.
Approval lifts the connection cap and removes the unreviewed notice from the consent screen. Nothing else about the app changes; the same client id, secret, tokens and webhook endpoints keep working.
Before you submit
The Submit tab checks that the app has:
- at least one redirect URI;
- at least one permission area;
- a privacy policy URL;
- a support email address.
Add a description, logo and website too: the reviewer and every practice see them.
What the reviewer looks at
- Whether the requested areas match what the app does. Ask for the smallest set that works.
- That the privacy policy covers patient data received from Smileline, and that the support address answers.
- That the redirect URIs belong to you and use HTTPS.
- How the app behaves when connected to a practice: the reviewer connects a Smileline practice and exercises it.
Outcomes
| Outcome | What happens |
|---|---|
| Approved | The cap and the notice go in both regions within minutes. You receive an email. |
| Changes requested | The reviewer's note appears on the Submit tab and by email. The app keeps working under the cap; address the note and submit again. |
| Disabled | Reserved for apps that break the terms. Every token is refused at once and every practice's endpoint for the app is archived. Contact support to discuss it. |
Later changes to an approved app — new redirect URIs, more areas, a new webhook URL — publish immediately and do not require a new review. A wider set of areas does not widen practices that already connected: each existing connection keeps the grant it was given.
Test with real practices
Apps are live in both regions from the moment they are created; what the unreviewed notice and the 25-practice cap mean while you build.
List patients GET
Paginated list. q is a typo-tolerant (trigram) search over name, email, phones, fiscal code and address (street, city, postal code). `filters` is URL-encoded JSON matching the PatientFilters schema; keys are AND-ed. sort=relevance ranks by similarity to q. embed=tags attaches each row's tags. Archived patients are excluded unless includeArchived=true or a status filter asks for archived.