API overview

The Waspito Developer API is a focused server-to-server interface for approved healthcare integrations. This reference documents only routes declared under Waspito Third-Party OAuth API Routes in routes/api.php; internal mobile, patient, doctor, payment, and platform APIs are outside this contract.

Integration model

flowchart LR
    A[Developer Console] -->|Create app| B[Client credentials]
    B -->|POST oauth token| C[Temporary Bearer token]
    C -->|Protected request| D[Waspito Developer API]
    D -->|JSON response| E[Your backend]
    E -->|Approved patient experience| F[Your application]

Your backend is the trust boundary. It exchanges application credentials, holds the temporary token, sends protected requests, and exposes only the minimum safe result to your own clients.

Base URL

https://app.waspito.com/api/v1/icers-bridge/ehealth-access

Use the host explicitly assigned to your environment. Do not assume that production credentials will work against a staging host, or that development credentials will work in production.

Public endpoint directory

Additional protected operations appear as individual menu items only after Developer Console authentication. Their pages also enforce authentication when opened directly.

Authentication boundary

Two different authentication moments are involved:

Signing in to the documentation does not replace the API Bearer token. Likewise, possessing an API token does not create a browser documentation session.

HTTP conventions

All documented requests use HTTPS and JSON.

Accept: application/json
Content-Type: application/json

Protected requests additionally use:

Authorization: Bearer YOUR_ACCESS_TOKEN

The token middleware also understands x-authorization, but the standard Authorization header is recommended for portability and compatibility with common HTTP clients.

Response envelope

Successful developer API responses use this structure:

{
  "data": {},
  "status": true,
  "message": "Human-readable result",
  "code": "_WT_CODE"
}

Application failures use the same top-level fields with status: false and an empty data value:

{
  "data": [],
  "status": false,
  "message": "Human-readable problem",
  "code": "_WT_CODE"
}

Laravel request validation failures may instead return HTTP 422 with a message and field-level errors object. Integrations should always evaluate the HTTP status first, then status and code when present.

Statuses you should handle

Versioning

The /api/v1 prefix identifies the major contract version. Additive response fields may be introduced without changing the major version, so clients should ignore unknown JSON properties and depend only on documented fields.

When a breaking version is introduced, use the documentation version selector to review its contract before changing your production base URL.

Security responsibilities

• Keep client credentials and Bearer tokens in backend secret storage.
• Send requests only over HTTPS.
• Redact credentials, phone numbers, dates of birth, and signed links from logs.
• Give production access only to services and people that need it.
• Treat returned patient and consultation data according to your privacy obligations.
• Rotate an application's credentials immediately if a secret is exposed.

Recommended integration lifecycle

1. Complete Getting started.
2. Implement and test Generate an access token.
3. Sign in to access approved protected endpoint documentation.
4. Exercise success, validation, authentication, and unavailable-service scenarios.
5. Complete the Integration checklist before launch.