How consumer apps, enterprise portals, and vertical-specific platforms (agri, healthcare, finance) integrate with the Signal Telecom Suite API. White-label ready, multi-tenant, schema-isolated.
Signal Telecom Suite is a platform, not an app. It exposes REST APIs that any frontend can consume.
For admin portals and operator dashboards. Returns tenant config and sets the tenant context.
POST /api/v1/tenant/login
Content-Type: application/json
{
"email": "ops@prairieconnect.us",
"password": "demo2024"
}
Response:
{
"tenant": {
"id": 2,
"name": "Prairie Connect Broadband",
"slug": "prairie",
"schema": "tenant_prairie",
"countries": ["US"],
"modules_enabled": ["SIG-ID", "SIG-PROV", ...]
}
}
After login, include X-Tenant-ID: 2 header on all subsequent API calls.
For consumer apps and self-serve portals. Authenticates by phone number + password.
POST /api/v1/auth/consumer-login
Content-Type: application/json
{
"phone": "+13125550101",
"password": "Signal2024!"
}
Response:
{
"customer_id": "069b5d5b-27b6-...",
"external_id": "CCA-US-d8d5f8e2",
"name": "Midwest Grain Co-op",
"tenant_id": 2,
...
}
Use the returned tenant_id as X-Tenant-ID header for subsequent calls.
Use customer_id for customer-specific API calls.
X-Tenant-ID: 2 # Required on every request Content-Type: application/json
List endpoints return paginated results:
GET /api/v1/customers/?limit=20&offset=0
{
"items": [...],
"total": 142,
"limit": 20,
"offset": 0
}
Every request is scoped to the tenant's PostgreSQL schema. Tenant 1 cannot see tenant 2's data. This is enforced at the database level (schema-per-tenant) and application level (tenant_id filtering).
A consumer app (like T-Mobile T-Life) needs these APIs:
| Feature | API Endpoint | Module |
|---|---|---|
| Login | POST /api/v1/auth/consumer-login | SIG-ID |
| Profile | GET /api/v1/customers/{id} | SIG-ID |
| Subscriptions | GET /api/v1/provisioning/subscriptions?customer_id={id} | SIG-PROV |
| Usage | GET /api/v1/rating/usage-summary/{id} | SIG-RATE |
| Bills | GET /api/v1/billing/invoices?customer_id={id} | SIG-BILL |
| Payments | GET /api/v1/payments/methods/{id} | SIG-PAY |
| Support tickets | GET/POST /api/v1/tickets?customer_id={id} | SIG-TKT |
| AI chat | POST /api/v1/ai/chat | SIG-AI |
| Plans | GET /api/v1/provisioning/plans | SIG-PROV |
// React / JavaScript
const API = 'https://api.telecom.signalailabs.com/api/v1';
const headers = {
'X-Tenant-ID': session.tenant_id,
'Content-Type': 'application/json',
};
// Get usage summary
const usage = await fetch(
`${API}/rating/usage-summary/${session.customer_id}`,
{ headers }
).then(r => r.json());
console.log(usage.total_mb); // 2750.0
console.log(usage.total_voice_min); // 100
console.log(usage.total_sms); // 20
A vertical platform imports common modules from sigcore as a Python package and adds its own domain-specific modules.
signal-agri/
src/sigagri/
marketplace/ # Agri-specific: listings, orders
inventory/ # Agri-specific: warehouses, stock
certifications/ # Agri-specific: organic, fair-trade
traceability/ # Agri-specific: batch tracking, QR
main.py # FastAPI app
portal/ # Farmer portal (React)
# sigagri/main.py imports common modules:
from sigcore.bss.identity.router import router as identity_router
from sigcore.bss.billing.router import router as billing_router
from sigcore.bss.payments.router import router as payments_router
from sigcore.bss.tickets.router import router as tickets_router
# ... plus agri-specific routers
from sigagri.marketplace.router import router as marketplace_router
| Module | What it provides | Agri example |
|---|---|---|
| SIG-ID | Customer identity, KYC, lifecycle | Farmer profiles, co-op registration |
| SIG-BILL | Invoicing, line items | Invoice farmers for marketplace fees |
| SIG-PAY | Payment methods, transactions | Mobile money, bank transfers |
| SIG-COL | Collections, dunning | Follow up on unpaid marketplace orders |
| SIG-TKT | Support tickets, SLA | Farmer support requests |
| SIG-TAX | Tax rules, calculations | Agricultural export duties |
| SIG-AI | Predictions, chat | Crop yield predictions, farmer chatbot |
| SIG-AUD | Audit trail | Compliance logging |
| SIG-NTF | Notifications | SMS alerts for order updates |
| Module | Purpose | Not in sigcore because... |
|---|---|---|
| Marketplace | Commodity listings, orders, pricing | Domain-specific to agriculture |
| Inventory | Warehouse, stock, movements | Physical goods, not services |
| Certifications | Organic, fair-trade, quality tests | Agriculture compliance |
| Traceability | Batch tracking, QR codes, chain of custody | Supply chain specific |
sigcore. If it's specific to one vertical, it stays in that vertical's package.
An enterprise self-serve portal lets business customers manage their own account without calling support.
| Feature | API |
|---|---|
| Login | POST /api/v1/auth/consumer-login |
| View invoices | GET /api/v1/billing/invoices?customer_id={id} |
| View subscriptions | GET /api/v1/provisioning/subscriptions?customer_id={id} |
| View usage | GET /api/v1/rating/usage-summary/{id} |
| Submit support ticket | POST /api/v1/tickets |
| View ticket history | GET /api/v1/tickets?customer_id={id} |
| Make payment | POST /api/v1/payments/ |
| Update profile | PATCH /api/v1/customers/{id} |
Never hardcode API URLs. Use environment variables:
# .env.production VITE_API_URL=https://api.telecom.signalailabs.com/api/v1 # In code const API = import.meta.env.VITE_API_URL;
| Environment | API URL |
|---|---|
| Local development | http://localhost:8000/api/v1 |
| Staging | https://api-staging.signalailabs.com/api/v1 |
| Production | https://api.telecom.signalailabs.com/api/v1 |
The platform API allows requests from configured origins. For a new consumer app,
add its domain to the CORS allow list in sigtel/main.py:
app.add_middleware(
CORSMiddleware,
allow_origins=[
"https://app.tracconnect.rw", # TrAC consumer app
"https://my.prairieconnect.us", # Prairie self-serve
"https://sandbox.signalailabs.com", # Sandbox portal
...
],
)
For MVNOs selling to corporate/enterprise customers with bulk SIM needs:
POST /api/v1/mvno/enterprise
{
"customer_id": "069b...", // Enterprise customer from SIG-ID
"account_name": "Infosys - Corporate Mobile",
"max_sims": 500,
"billing_mode": "cost_center", // consolidated, per_sim, cost_center
"volume_discount_pct": 15.0
}
POST /api/v1/mvno/enterprise/bulk-assign
{
"enterprise_account_id": 1,
"iccids": ["8991000000001", "8991000000002", ...], // up to 500 per call
"cost_center": "BLR-ENG",
"department": "Engineering"
}
Response: { "assigned": 10, "failed": 0, "errors": [] }
| Endpoint | Purpose |
|---|---|
POST /mvno/enterprise/{id}/bulk-activate | Activate all assigned SIMs, auto-assign MSISDNs |
POST /mvno/enterprise/{id}/bulk-suspend | Suspend all or by cost center |
GET /mvno/enterprise/{id}/sims | List SIMs with cost center/department filter |
GET /mvno/enterprise/{id}/usage-summary | Aggregated usage by cost center & department |
| Mode | Description |
|---|---|
| consolidated | One invoice for all SIMs. Enterprise pays one bill. |
| per_sim | Separate line item per SIM on the invoice. |
| cost_center | Grouped by cost center for internal chargeback. IT dept sees breakdown. |
Download the OpenAPI spec to generate client SDKs in any language:
| Spec | URL | Use for |
|---|---|---|
| Full API | /openapi.json | Complete platform integration |
| BSS only | /docs/bss/openapi.json | Billing, payments, tickets |
| OSS only | /docs/oss/openapi.json | Device management, RADIUS |
| Platform | /docs/platform/openapi.json | AI, analytics, notifications |
Generate a TypeScript client:
npx openapi-typescript-codegen \ --input https://api.telecom.signalailabs.com/docs/bss/openapi.json \ --output src/api \ --client fetch
Explore the full API
API Documentation Index →