Entities and operations
This is the reference page for understanding:
- which main API entities exist;
- how you can interact with each (read/write);
- which OAuth scope is required for each resource.
- which applicative permission is required for each specific route.
For the full scope list, how they work, and how to manage them, see Scopes and authentication.
Each call may require two authorization layers: the OAuth scope (token) and the user's applicative permission in GipoNext. This page shows both: the main scope per resource and, under each resource, the permissions required for each route.
For full details (required fields, enums, types) always use Swagger UI.
Quick map: resources, operations, and scopes
| Resource | Main scope | Read | Write |
|---|---|---|---|
| UserInfo | n/a (authenticated user context) | Yes | No |
| Patients | giponext.patients | Yes | Yes |
| Agendas | giponext.agenda | Yes | No |
| Appointments | giponext.agenda | Yes | Yes |
| Availabilities | giponext.agenda | Yes | No |
| Treatments | giponext.treatments | Yes | No |
| Price lists | giponext.treatments | Yes | No |
| Episodes | giponext.episodes | Yes | Yes |
| Medical reports | giponext.medicalreports | Yes | Yes |
| Invoices | giponext.invoices | Yes | Yes |
401 - Unauthorized
When the user is not correctly authenticated the error will be:
| Header | Value |
|---|---|
Authorization | <missing_wrong_or_expired_token> |
Accept | application/json |
403 - Forbidden
The user is correctly authenticated but lacks sufficient privileges
Missing claim
In the authentication preceding the call, a claim required for the call was not specified
| Header | Value |
|---|---|
Authorization | {access_token} |
Accept | application/json |
Insufficient user permissions
When the connected user cannot access the requested resource, you will get a message like this:
| Header | Value |
|---|---|
Authorization | {access_token} |
Accept | application/json |
Resources
UserInfo
- Required prefix
/v2/userinfo - Scope
authenticated user context
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | no specific permission (authenticated user) |
This is the starting point for every integration: it returns the authenticated user context and the tenants they can access. In practice you use it to understand "who is operating" and which structures you can work with.
From here you obtain the tenantId for subsequent calls under /v2/tenants/{tenantId}/....
Tenant
APIs allow for a user to be associated with multiple tenants. Currently this is not possible in GipoNext, but handling this case is recommended.
User not present in GipoNext
The identity provider (GipoAccount) and GipoNext are distinct. A user may be correctly authenticated and active in GipoAccount but not present in GipoNext.
In that case you may receive a 200 with some user information but no tenant information. The user should be considered invalid.
| Header | Value |
|---|---|
Authorization | Bearer {access_token} |
Accept | application/json |
Patients
- Required prefix
/v2/tenants/{tenantId}/patients - Scope
giponext.patients
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | POST / | |
| Swagger - Scalar | GET /{patientId} | |
| Swagger - Scalar | PUT /{patientId} |
This resource represents patient demographics and related operational management. It is typically the base for integrations that create, update, or synchronize demographics with external systems (CRM, portals, administrative middleware).
Agendas
- Required prefix
/v2/tenants/{tenantId}/agendas - Scope
giponext.agenda
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | or |
| Swagger - Scalar | GET /{agendaId} | or |
Agendas describe the calendars available in the tenant (per doctor, resource, or station). In practice they are the reference for understanding where and how to schedule visits and activities.
Appointments
- Required prefix
/v2/tenants/{tenantId}/appointments - Scope
giponext.agenda
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{appointmentId} | |
| Swagger - Scalar | POST / | |
| Swagger - Scalar | PUT /{appointmentId} | |
| Swagger - Scalar | PUT /{appointmentId}/status | |
| Swagger - Scalar | PUT /{appointmentId}/payment | |
| Swagger - Scalar | DELETE /{appointmentId}/payment | |
| Swagger - Scalar | DELETE /{appointmentId} | |
| Swagger - Scalar | POST /{appointmentId}/checkin |
This is the core resource for planning: you can read existing appointments, create new ones, update them, and delete them. It is the base for online booking, front desk, reminder, and calendar sync integrations.
Treatments
- Required prefix
/v2/tenants/{tenantId}/treatments - Scope
giponext.treatments
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{treatmentId} |
Treatments represent the catalog of deliverable activities. In integration they are used to build external catalogs, associate appointments with services, and correctly compute the economic/operational context of bookings.
Price lists
- Required prefix
/v2/tenants/{tenantId}/pricelists - Scope
giponext.treatments
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{priceListId} | |
| Swagger - Scalar | GET /{priceListCode} |
Price lists define pricing and validity rules. They are useful when you need to show prices, run preliminary checks, or keep the economic alignment between GipoNext and external applications.
Episodes
- Required prefix
/v2/tenants/{tenantId}/episodes - Scope
giponext.episodes
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{id} | |
| Swagger - Scalar | POST / | |
| Swagger - Scalar | PUT /{id} | |
| Swagger - Scalar | DELETE /{id} |
Episodes group clinical and administrative activities across a patient pathway. They are essential when an integration must follow a complete process (intake, progress, closure, and links to economic components).
Invoices
- Required prefix
/v2/tenants/{tenantId}/invoices - Scope
giponext.invoices
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{invoiceId} | |
| Swagger - Scalar | GET /{invoiceId}/pdf | |
| Swagger - Scalar | POST / | |
| Swagger - Scalar | POST /{invoiceId}/reimbursements |
This resource covers the invoicing cycle: document lookup, creation, and related outputs. If you integrate administrative or accounting flows, it is the main bridge between clinical and economic operations.
Medical reports
- Required prefix
/v2/tenants/{tenantId}/medicalreports - Scope
giponext.medicalreports
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | POST / | |
| Swagger - Scalar | GET / | |
| Swagger - Scalar | GET /{medicalReportId} | |
| Swagger - Scalar | GET /{medicalReportId}/pdf |
Medical reports allow publishing and managing clinical documentation. This area is typical for integrations with diagnostic systems, document repositories, patient portals, or report delivery workflows.
Maximum PDF size
When creating a medical report (POST /), the attached PDF file must not exceed 25 MB. Requests with larger files will be rejected.
Availabilities
- Required prefix
/v2/tenants/{tenantId} - Scope
giponext.agenda
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET /availabilities | |
| Swagger - Scalar | GET /treatments/{treatmentId}/listprices/{priceListId}/availabilities |
Availabilities are used to propose bookable slots reliably. They are especially useful in external booking flows where you need to validate time windows and consistency with organizational/economic context.
Locations
- Required prefix
/v2/tenants/{tenantId}/locations - Scope
authenticated user tenant context
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | no specific permission (authenticated user with tenant access) |
| Swagger - Scalar | GET /{locationId} | no specific permission (authenticated user with tenant access) |
Locations represent the tenant's operational sites. They are useful when the integration must distinguish between multiple physical sites (e.g. clinics, satellite offices) to associate resources, agendas, or appointments with the correct site.
TenantInfo
- Required prefix
/v2/tenants/{tenantId}/info - Scope
authenticated user tenant context
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET / | no specific permission (authenticated user with tenant access) |
Returns general information about the tenant (business name, address, configurations). Useful for displaying practice details in your application's interface or for verifying the tenant configuration.
Accounting
- Required prefix
/v2/tenants/{tenantId}/accounting - Scope
giponext.invoices
| Specs | Operation | Permission |
|---|---|---|
| Swagger - Scalar | GET /sections | |
| Swagger - Scalar | GET /issuers | |
| Swagger - Scalar | GET /issuers/{issuerId} |
The accounting area provides access to economic summary data and invoice sections. It is the integration point for external accounting or management systems that need aggregated data.
FAQ
How do I trace doctors from an invoice?
The flow to follow across resources is:
Invoice → Items → LinkedPractices → Episode → Doctors- From the invoice, navigate to Items → LinkedPractices to obtain:
- episodeId (Episode)
- practiceId (Detail line)
- Call the Episodes API:
GET /episodes/{episodeId} - In the response, filter the practices array using the practiceId obtained in step 1:
practices[practiceId].doctors
📌 Note
Each invoice line can have multiple LinkedPractices and each practice can have multiple doctors.
How are normative references related to VAT exemptions coded in API responses?
| Normative Reference | API Code |
|---|---|
| Art. 10 n. 18 del DPR 26/10/1972 n. 633 | Art10_n18 |
| Art. 1, comma 58, legge n. 190/2014 | Art1_Comma58_Legge190_2014 |
| Art. 1, comma 100, legge n. 244/2007 | Art1_Comma100_Legge244_2007 |
| Art. 13, comma 5 dpr 633/72 | Art13 |
| Ex art. 10, comma 1, n. 20, del Dpr 633/1972 | Art10_Comma1_n20 |
| Art.10 n.20 del DPR 26/10/1972 n.633 | Art10_n20 |
| ART.17 DPR 633/1972 | ART17_DPR_633_1972 |
| Ex art. 10, comma 8, del Dpr 633/1972 | Art10_Comma8_633_1972 |
| Art. 124 DL 34/2020 | Art124_DL_34_2020 |
| Art. 10 n. da 1 a 9 | Art10_nda1a9 |
| Art. 1 comma 452 L. 178 del 30/12/2020 | Art1_Comma452_Legge178_2020 |
| Art. 10, comma 1, n. 27-quinquies), Dpr 633/72 | Art10_Comma1_N27_quinquies |
| Esente Iva Art.10 punto 21 del DPR 633/72 | Art10_Punto21_DPR_633_1972 |
| Articolo 8 comma C - DPR 633/72 | Art8_CommaC_DPR633_72 |
| Articolo 2, comma 3, lettera a, del DPR 633/72 | Art2_Comma3_LetteraA_DPR633_1972 |
| Art. 8 comma 35 L. 67/1988 | Art8_Comma35_L_67_1988 |
| Art. 8 co 2 Dpr 633/72 | Art8_Co2 |
| Art. 26 DPR 633/72 | Art26_DPR633_72 |
Operational notes
- Invoices: invoice creation is sequential per section.
- TLS: transport security requirements are in TLS.
- Operational FAQ: see FAQ.
For query parameters (filters), status codes, and full payloads, refer to Swagger.