Skip to content

Implementation Requirements for NSPS Connector

This section outlines the essential technical and functional requirements for developing NSPS connector. Adherence to these requirements ensures correct and secure integration with NSPS platform, as well as reliable interaction with the external system.

General Requirements

Every NSPS connector must comply with the following general requirements:

  • Authentication of Requests: All incoming requests to the connector from NSPS must be authenticated using a Bearer token. This ensures security and prevents unauthorized access.
  • Event Payload Schema Parsing: The connector must be capable of correctly parsing and validating the incoming JSON request body, which conforms to the NSPS event structure.
  • Handling Specific Events: The connector must be designed to process specific event types (e.g., "SIM activated", "Plan changed", etc.) that it is intended to translate.
  • Configurable Settings for External API:
    • API Base URL: Ability to configure the base URL of the ES with an optional base path (e.g., https://external-system.com or https://external-system.com/api/v1).
    • API Access Credentials: Configuration of credentials for accessing the external system. This can be Basic Auth, Bearer Auth with a static token, or support for JWT (if the ES requires it, the connector should work with access_tokens and refresh_tokens).

Response Codes

The connector must provide clear and standardized responses for all requests:

  • Successfully Processed Events (2XX): For successfully processed events, the connector should return HTTP status codes in the 2XX range (e.g., 202 Accepted). The response may include an optional JSON body with a success message.
  • Unsuccessfully Processed Events (4XX and 5XX): For events that were not successfully processed, the connector must return appropriate HTTP status codes 4XX (client errors) or 5XX (server errors). The response body must contain a JSON object with a human-readable explanation of the error cause. Refer to the Error Handling section for the detailed structure.

Mandatory Endpoints

Every NSPS connector must implement two primary endpoints:

  1. GET /health

    • Purpose: This endpoint is used to check the availability and operational status of the connector itself.
    • Expected Response: Should return an HTTP status 200 OK with an optional empty or informative JSON body.

  2. POST /process-event

    • Purpose: This method is used by the NSPS as the target URL for sending events.
    • URL Structure: The URL may or may not contain a path (e.g., https://connector.com or https://connector.com/api/events).

OpenAPI Specification

For better understanding and integration, you can view or download an example of the OpenAPI specification for the NSPS connector below. It details the request structure and expected responses.

  • View OpenAPI.json

    Explore the API structure in JSON format directly in the browser.

    Open file

  • Download OpenAPI.json

    Download the complete OpenAPI specification for local use or integration.

    Download file

For an example implementation, please refer to the WTL HLR/HSS Connector.