OITVOIP: Access Platform APIs
Developer guide for accessing platform APIs including NetSapiens API v1 and v2, OneBill billing API, and Datagate analytics API. Covers authentication methods, documentation links, common use cases, and community resources.
Written by Marissa Orsini
Updated at April 6th, 2026
Table of Contents
Scope
Intended Audience: Partners, Resellers, Developers
This article covers the APIs available on the OITVOIP platform, how to obtain credentials, where to find documentation, and how to connect with the developer community. Whether you are automating provisioning, pulling call records, or building a custom integration, start here.
Requirements
- An active reseller or office manager account on the platform
- API credentials (see Get API Credentials below)
- A tool for making HTTP requests (cURL, Postman, or your preferred language/library)
Get API Credentials
There are three authentication methods available. Each has a different setup process and is suited to different use cases.
| Method | Works With | How It Works | How to Get It | Best For |
|---|---|---|---|---|
| API Key (v44+) | API v2 only | Persistent key with scoped permissions. No token refresh needed. Passed as a Bearer token. | Request from your service provider, or sign up at the developer sandbox to get a test key instantly | Server-to-server integrations, scripts, automations |
| OAuth 2.0 | API v1 and v2 | Client ID + Client Secret + your portal username/password are exchanged for a short-lived access token via /ns-api/oauth2/token. |
Request a Client ID and Client Secret from your service provider | User-delegated access, browser-based integrations |
| JWT (v44+) | API v1 and v2 | JSON Web Tokens produced by the OAuth flow. Supports RS256 signing and revocation by token or user ID. | No separate credential needed — JWTs are returned automatically when you authenticate via OAuth | Stateless auth, microservices, token-based architectures |
Which Method Should I Use?
- Starting a new integration? Use an API Key. It is the simplest path — one key, no token refresh, no OAuth dance. Request one from your service provider or grab a test key from the developer sandbox.
- Building an app that acts on behalf of users? Use OAuth 2.0. You will need a Client ID and Client Secret from your service provider, then your app exchanges those plus the user's portal credentials for an access token.
- Already using OAuth and want stateless tokens? You are already getting JWTs — the OAuth token endpoint returns them automatically on v44+.
Note: API credentials grant programmatic access to your account. Treat them like passwords — store them securely, never commit them to source control, and rotate them if you suspect a compromise.
API Key Scopes
API keys support tiered permissions that match the portal's access model:
| Scope | Access Level |
|---|---|
| Reseller | Full access to all domains within your territory |
| Office Manager | Access limited to a single domain |
| Basic User / Advanced User | User-level access (limited to own extension data) |
Platform API v2
Version Requirements
API v2 requires SNAPsolution v44 or later. If you are unsure which version your server runs, check with your service provider.
API v2 is the current, actively developed API. It uses a modern RESTful design with OpenAPI 3.1 documentation and supports API Key, OAuth, and JWT authentication.
Documentation
| Resource | URL |
|---|---|
| Hosted documentation (guides + reference) | https://docs.ns-api.com/ |
| Self-hosted Swagger UI (v44.3+) | https://<your-server-fqdn>/ns-api/openapi |
| OpenAPI spec (JSON) | https://<your-server-fqdn>/ns-api/webroot/openapi/openapi.json |
| v1 to v2 migration guide | docs.ns-api.com/docs/v1-migration-to-v2 |
| Developer sandbox | docs.ns-api.com/docs/developer-sandbox-ns-apicom |
The self-hosted Swagger UI on your own server lets you browse endpoints and test API calls directly against your environment. The OpenAPI JSON spec can be imported into tools like Postman for offline exploration.
Common Use Cases
Provisioning (Most Common)
Automate the creation and management of users, extensions, devices, and domains. Typical provisioning workflows include:
- User onboarding: Create a subscriber, assign an extension, and configure a device in a single script
- Bulk operations: Provision dozens of extensions from a CSV or CRM export
- Device management: Add, update, or remove SIP devices programmatically
- Domain setup: Configure new customer domains with default call routing and auto-attendants
Other Use Cases
| CDR & Reporting | Pull call detail records for billing reconciliation, usage dashboards, or analytics pipelines |
| Call Control | Initiate calls (click-to-call), transfer active calls, and monitor presence/status |
| Number Management | Query DID inventory, assign numbers to extensions, and manage number routing |
Platform API v1 (Legacy)
API v1 remains functional and is available on all server versions. It uses OAuth 2.0 authentication exclusively (API keys are not supported for v1).
| Resource | URL |
|---|---|
| Self-hosted API documentation | https://<your-server-fqdn>/ns-api/apidoc/ |
| API doc collection (JSON) | https://<your-server-fqdn>/ns-api/webroot/apidoc/api_doc_collection.json |
Note: As of February 2026, v1 documentation is only available via the self-hosted path on your server. The previously hosted external documentation has been retired. New integrations should use API v2 where possible.
Billing API (OneBill)
The OneBill API provides programmatic access to billing data, invoices, and subscription management. Use it to integrate billing workflows with your own systems or build custom billing dashboards.
| Developer documentation | https://dev.onebillsoftware.com/ |
| Access | Contact your service provider to request OneBill API credentials |
Usage & Billing Analytics API (Datagate)
The Datagate API provides access to usage data, billing analytics, and cost management. It is commonly used to sync billing data with PSA tools like ConnectWise or Autotask.
| Developer documentation | https://developer.datagate-i.com/ |
| Access | Contact your service provider to request Datagate API credentials |
Community & Developer Resources
Connect with other developers building on the platform. Share what you have built, ask questions, and find inspiration for your next project.
| Resource | Description |
|---|---|
| Discord: Development | Ask technical questions, get help with API integrations, and discuss development topics with the community |
| Discord: Caring is Sharing | Show off what you have built — automations, integrations, dashboards, and more |
| Join the Discord Server | Not on the Discord yet? Join here to access the development and community channels |
Frequently Asked Questions
Can I use my portal login credentials to access the API?
Not directly. You need API credentials (an API key or OAuth client ID/secret) issued by your service provider. Once you have an OAuth client, you use your portal username and password as part of the OAuth token request — but the client registration itself must come from your provider.
What is the difference between API v1 and v2?
API v2 is the current, actively developed version with modern RESTful design, OpenAPI documentation, and support for persistent API keys. API v1 is still functional but only supports OAuth authentication and its external documentation has been retired. New integrations should use v2.
Where can I test API calls safely?
The developer sandbox at ns-api.com is available to all clients and third-party partners. When you sign up, a reseller-scoped account and API key are automatically created for you — no provider interaction needed. You can also use the self-hosted Swagger UI on your server at /ns-api/openapi (v44.3+) to explore and test endpoints directly against your own environment.
Can I use one API key for both v1 and v2?
No. API keys only work with API v2 (requires v44+). If you need to access v1 endpoints, use OAuth 2.0 authentication. OAuth works with both v1 and v2.
How do I get help if I am stuck?
Join the Discord server and post in the Development channel — the community is active and happy to help with API questions. For account-specific issues (credentials, permissions, server access), contact your service provider's support team.