System, Auth & SaaS Management APIs


0. Developer Getting Started, Security & API Access Rules

1. How to Register & Obtain an API Key

  1. Create an Account: Visit /register.php or call POST /api/v1/auth/register with your email and password.
  2. Choose a Subscription Plan: Review options at /pricing.php and activate your desired tier (Starter, Growth, Scale, or Enterprise).
  3. Obtain Your API Key: Log in to your Developer Dashboard to copy your production key (sk_live_...).
  4. Configure Anti-Theft Domain Whitelist: In your dashboard, specify your client domains (e.g. app.mywebsite.com, localhost, *.client.in). Requests originating from unlisted domains will be blocked immediately with HTTP 403.

2. Authentication & Request Headers

Every API request must supply valid authentication credentials using either of the following standard headers:

X-API-Key: sk_live_your_api_key_here

or

Authorization: Bearer sk_live_your_api_key_here
Content-Type: application/json

3. Tier-Based API Access Hierarchy

Plan Tier Minimum Level Monthly Quota Master Reports Unlocked API Scope
Starter Level 1 1,000 calls 10 (EN) 18 APIs: Core Astronomy, 16 Vargas (D1-D60), Vimshottari Timeline, Basic Panchang, Muhurta, SVG charts
Growth Level 2 10,000 calls 30 (4 Langs) 42 APIs: Level 1 + KP 4-Fold Significators, 36-pt Synastry Match, 50+ Yogas, 6 Doshas, Varshaphal, Transits
Scale Level 3 50,000 calls 250 (4L + 4T) 57 APIs: Level 2 + Level 4 Sookshma Micro-Timing, Double Transits, KP Horary 1–249, BTR, AI Context Bridge
Enterprise Level 4 100,000 calls 1,000 (4L + 4T) All 68 APIs: Level 3 + Real-Time Dasha/Transit Webhooks, Multi-Key Team APIs, Batch Knowledge Synthesis
Super Admin Level 4 Unlimited Unlimited Unrestricted system-wide access to all calculation, configuration, and telemetry APIs

4. HTTP Status Codes & Structured Error Responses


1. Developer Authentication & Registration

1. Name

Developer Authentication & Registration

2. Purpose

Provides account creation (/auth/register) and JWT token authentication (/auth/login) for developers creating accounts on the RBOS.in SaaS platform.

3. Endpoint

POST /api/v1/auth/register & POST /api/v1/auth/login

4. Auth

Type: None (Public Auth Endpoint)

5. Request Headers

Header Required Description
Content-Type Yes Must be application/json.

6. Request Payload

{
  "email": "developer@example.com",
  "password": "SecurePassword123!"
}

7. Request Params Table

Field Type Required Description Allowed Values Validation Example
email string Yes Valid developer email address String Valid Email Regex "developer@example.com"
password string Yes Account password String Min 8 characters "SecurePassword123!"

8. Request Example

{
  "email": "developer@example.com",
  "password": "SecurePassword123!"
}

9. Success Response

Status: 200 OK (or 201 Created)

{
  "status": "success",
  "message": "Authentication successful",
  "data": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "user": {
      "id": 1,
      "email": "developer@example.com",
      "plan": "free"
    }
  }
}

10. Response Fields Table

Field Type Description Nullable Example
status string Result status No "success"
data.token string Bearer JWT Authentication Token No "eyJhbGci..."
data.user.id integer Developer account User ID No 1
data.user.email string Developer account email No "developer@example.com"
data.user.plan string Subscription plan tier No "free"

11. Status Codes Table

Code Meaning When Returned
200 OK Login successful.
201 Created Registration successful.
400 Bad Request Missing credentials.
401 Unauthorized Invalid email or password.
409 Conflict User email already registered.

12. Error Examples

{
  "status": "error",
  "message": "Invalid email or password."
}

13. Frontend Usage Notes

14. Validation Rules

15. Business Rules

16. Security Notes

17. Performance Notes

19. Example Frontend Flow

  1. Developer submits login form.
  2. App posts to /api/v1/auth/login.
  3. App redirects to /dashboard/me.

20. Complete Example

Request:

POST /api/v1/auth/login HTTP/1.1
Host: api.rbos.in
Content-Type: application/json

{
  "email": "developer@example.com",
  "password": "SecurePassword123!"
}

Response:

{
  "status": "success",
  "data": { "token": "jwt_token_here", "user": { "id": 1, "email": "developer@example.com" } }
}

Explanation: Authenticates developer and returns JWT token.


2. API Health Check

1. Name

API Health Check

2. Purpose

Used by load balancers, uptime monitors, and frontend status bars to verify API engine operational status.

3. Endpoint

GET /api/v1/health

4. Auth

Type: None

5. Request Headers

Header Required Description
Accept No application/json

6. Request Payload

None (GET Request)

7. Request Params Table

None

8. Request Example

GET /api/v1/health

9. Success Response

Status: 200 OK

{
  "status": "success",
  "message": "RBOS Engine API is running"
}

10. Response Fields Table

Field Type Description Nullable Example
status string Health status No "success"
message string Operational status message No "RBOS Engine API is running"

11. Status Codes Table

Code Meaning When Returned
200 OK API is healthy.

12. Error Examples

500 Internal Server Error if database or Swiss Ephemeris binaries fail initialization.

13. Frontend Usage Notes

14. Validation Rules

None.

15. Business Rules

16. Security Notes

17. Performance Notes

19. Example Frontend Flow

  1. Developer portal loads.
  2. Portal sends GET /api/v1/health.
  3. Green indicator rendered.

20. Complete Example

Request:

GET /api/v1/health HTTP/1.1
Host: api.rbos.in

Response:

{
  "status": "success",
  "message": "RBOS Engine API is running"
}

Explanation: Confirms engine availability.