T
TOMO
Developer Docs
⌘K
BETA These docs are under partner review. Some features described are roadmap items, not yet shipped. Verify against your sandbox before relying on any contract.
Docs  ›  QUICKSTART

TOMO Partner Quickstart — Zero to First Call in 30 Seconds

Audience: engineering team at a business that wants to plug into TOMO. You either have an existing MCP server, an existing REST API, or you're building from scratch.

What you walk away with after this doc:

  • Sandbox credentials issued (5 minutes)
  • A real MCP / API call that TOMO accepts (15 minutes)
  • An understanding of how your tools surface to TOMO users (silent — you don't need anyone's approval to test)

Production access turns on after a separate compliance review (24-72h).

TL;DR — The 30-second loop

1. Visit  https://www.automobnxt.com/login
2. Click  "Become a partner"
3. Click  "Plug in your API"
4. Sign up with corporate email (any domain — eng@yourcompany.com)
5. Enter the 6-digit code from your inbox
6. You're in. Sandbox credentials shown on screen. First curl example below.

Three paths — pick yours

Path A — You already have an MCP server

The fastest path. TOMO probes your endpoint, calls tools/list, projects your tools into our intent catalog automatically.

You provide:

  • Your MCP endpoint URL (e.g., https://api.yourcompany.com/mcp)
  • That's it.

TOMO does:

  • Probe tools/list — discover what you serve
  • Match each tool to a TOMO intent in docs/intents/_INTENT_CATALOG.md
  • Light up your sandbox listing within 30 seconds of probe success

Time to sandbox: 30 seconds.

Path B — You have a REST or GraphQL API

You declare your offerings via TOMO's manifest editor. We wrap your API as MCP internally so TOMO's orchestrator can dispatch to you uniformly.

You provide:

  • Your API base URL
  • Auth method (API key / OAuth 2.1 / signed header)
  • Manifest declaring which TOMO intents you serve, your pricing range, your service area, your TTBS self-rated signals

TOMO does:

  • Run a synthetic call against your API to verify reachability + auth
  • Generate the MCP wrapper from your manifest
  • Light up sandbox

Time to sandbox: 5-15 minutes per intent.

Path C — You're building from scratch

No API, no MCP. Build a small Express/FastAPI/Go service that implements one intent, deploy it anywhere (Cloud Run, Vercel, Railway, your own metal), then take Path A.

TOMO provides:

Time to sandbox: depends on how fast your team ships. Reference impls deploy in under an hour.

After signup — what you see

Once your 6-digit code verifies, you land in the Tier 1 dashboard at https://www.automobnxt.com/?dev=sandbox-api (during testing). Three setup steps:

1. Issue sandbox credentials       (Step 1 — mandatory)
2. Submit your service manifest    (Step 2 — mandatory)
3. Verify your business compliance (Step 3 — for production access)

You can do steps 1 and 2 in any order. Step 3 gates production traffic.

Step 1 — Sandbox credentials

Click Issue creds. The dashboard immediately issues:

client_id:        tomo_sandbox_<24 hex chars>
client_secret:    <shown ONCE, copy now — full secret never visible again>
customer_id:      cust_<12 hex chars>
webhook_url:      (you fill in your endpoint)
webhook_signing_key: (issued when you save webhook_url; shown ONCE)

Copy client_secret immediately. It's redacted on every subsequent view. Use Rotate to issue a fresh secret if you lose it (old secret stops working in 24h).

Your first call (curl)

curl -X POST https://www.automobnxt.com/api/v1/business/tier1/credentials/<your_uid>/test-call \
  -H "Content-Type: application/json" \
  -d '{
    "user_intent": "ride"
  }'

You should see:

{
  "ok": true,
  "intent": "mobility.book_intracity_ride",
  "stub_response": {
    "options": [
      {
        "id": "stub_option_1",
        "vehicle_kind": "sedan",
        "fare": { "total_inr": 320 },
        "eta": { "pickup_minutes": 4 }
      }
    ]
  },
  "note": "This is a stub. Day 6 wires through the live orchestrator..."
}

You just made your first authenticated call to TOMO. Total elapsed time: ~30 seconds from signup.

Step 2 — Declare your manifest

Click Submit your service manifest. The editor opens. For each intent you serve, fill in:

  • intent — exact full ID from docs/intents/_INTENT_CATALOG.md, e.g. food.order_delivery
  • domain — derived from intent namespace, e.g. food
  • pricing.min/max — your floor and ceiling per closed intent (helps TTBS budget scoring)
  • service_area — list of cities or pincodes you cover
  • ttbs_signals — your self-rating on time/taste/budget/safety (0.0-1.0 each)
  • completion_callback — your endpoint TOMO calls back to (you don't actually call it from here; you POST to TOMO's CPC webhook on close — see WEBHOOK_SIGNING.md)
  • widget_type — which TOMO chat widget renders your results

Live YAML preview shows what TOMO stores. You can copy that YAML and version-control it externally.

Submit your draft. Status flips to pending_review and an admin review-queue entry is created. You can keep iterating in sandbox while waiting.

Step 3 — Compliance verification

Required only for production access. Sandbox traffic continues without this.

Upload:

  • GSTIN
  • Domain-specific licenses (FSSAI for food, RERA for real estate, fitness/insurance/permit for mobility, etc. — see your intent's spec for exact list)
  • Privacy policy URL (must be live and accessible)
  • Business legal entity type (private limited / LLP / partnership / proprietorship / individual)

TOMO admin reviews within 24-72h. Approval flips your status from sandbox → live.

Implementing tools (the actual work)

Once you have credentials and a manifest, the real engineering is implementing the tools required by your intents. Every intent spec in docs/intents/<intent>.md lists:

  • §3 — exact tools you must implement (search_*, get_*, create_*, cancel_*, track_*, etc.)
  • §4 — exact response shape (every field REQUIRED, no optionals — see Anti-Fabrication)
  • §6 — controlled vocabularies (no free-text in enum slots)

Read the gold reference: docs/intents/travel.book_hotel.md. It's the most complete example. Every other intent follows the same structure.

Anti-fabrication

The hardest part of integrating with TOMO isn't the tools — it's the completeness rule.

Every field in every response is REQUIRED. There is no "optional." If your system can't surface a field that the spec lists, you cannot list that intent on TOMO until you collect, derive, or contract a third-party data provider for that field.

This is harder than industry norm. It's intentional. TOMO Intelligence requires complete signal — incomplete listings are not a soft choice, they are a rejection condition.

Specifically forbidden (these violate TOMO's source-blind ranking contract — fields you must not return):

  • paid_placement_score, ad_bid, sponsored_rank, promotion_priority
  • kickback_amount, referral_fee_kickback, _partner_revenue_share
  • artificial_urgency_text (without backing inventory data)
  • ai_generated_photo (must be false)
  • Commission-based response shaping

Status — enforcement (honest): today, these rules are reviewed manually during compliance approval before your status flips to live. Server-side automated ingest rejection of forbidden fields is on the roadmap, not yet shipped. Violations found post-launch are handled by manual admin review. (planned: automated ingest scanner)

The full anti-fabrication rule list is in §13 of every intent spec. Read it carefully — these aren't suggestions.

Webhook signing — the close-intent POST

When the user completes the action you served (delivery delivered, ride completed, hotel checked in, etc.), you POST to TOMO's CPC webhook:

POST https://www.automobnxt.com/api/v1/cpc/mcp_provider/<your_partner_id>
Headers:
  Content-Type: application/json
  X-TOMO-Timestamp: <unix_ms>
  X-TOMO-Signature: sha256=<hex_hmac>
Body:
  { intent, external_id, amount_inr, closed_at, status, ... intent-specific fields }

The HMAC-SHA256 is computed over ${timestamp}.${rawBodyJSON} with your webhook_signing_key (issued in Step 1).

Examples in Node.js, Python, and Go: WEBHOOK_SIGNING.md.

TOMO charges 10% on amount_inr — and amount_inr is your NET supplier revenue. That means base price plus any supplier-kept fees and surge. Excluded from the commission base: GST (goes to government), tips you pre-collect for your driver/staff, third-party pass-through fees you don't keep. Report those in the dedicated payload fields:

{
  "intent": "ride.request",
  "external_id": "trip_abc123",
  "amount_inr": 240,        // NET supplier revenue (commission base = 10% × this)
  "gst_inr": 12,            // government — not commissioned
  "tips_inr": 30,           // driver — not commissioned
  "pass_through_inr": 0,    // any third-party fee you don't keep — not commissioned
  "closed_at": "2026-05-11T19:42:00Z"
}

No subscription fee, no setup fee, no inflated CPC.

Going live

After compliance approval, your status flips to live. TOMO's orchestrator now routes real user intents to your tools alongside other live partners serving the same intent. Ranking is source-blind via TTBS — your scoring is determined by:

  • Your manifest's self-declared TTBS signals
  • Your live performance (latency, success rate, ratings)
  • The user's preferences and DNA

No partner has a paid path to the top. No partner gets favorable treatment because of commission negotiations. TTBS is the only ranking input.

Common questions

Do users see "powered by [my brand]"?

Yes — your brand name and source label appear on every result card we render in TOMO chat. Users tap your row, see your supplier badge, complete via your flow. TOMO is the orchestrator, not the merchant of record. (planned: logo + customer support phone fields on the supplier badge — not yet shipped)

Can I see my TTBS score?

No. Partners cannot see how individual listings rank. This is by design and prevents gaming. (planned: a partner-facing CPC ledger view — completed orders, commission earned, per-intent breakdown — not yet shipped. Today the ledger data is recorded server-side via your CPC webhook posts but no read-side dashboard surfaces it yet.)

What if my response includes a forbidden field?

Today, forbidden fields (see §Anti-fabrication above) are caught during compliance review before your status flips to live. After launch, violations are handled through manual admin review and may result in your status being set to suspended. (planned: automated server-side ingest scanner that rejects responses at call time + sandbox dashboard error log + automated three-strikes suspension counter — none of these are shipped yet.)

What if my SLA degrades?

Today, SLA management is manual — performance issues are reviewed by the admin team and your status may be set to suspended until resolved. (planned: automatic latency-p95 monitoring with auto-removal from the live pool and auto-rejoin on recovery — not yet shipped.)

Do I have to implement EVERY required field?

Yes. That's the rule. If your system genuinely doesn't have the data, build the collection pipeline before listing. Manifest submission validates the core fields (intent, domain, pricing.min/max, service_area); full per-field completeness is checked during the compliance review that gates production access.

Can I test in production without going through compliance?

No. Sandbox accounts are gated from the live supply pool by your status field — your tools are never dispatched to real users until that flips to live after compliance approval. Production requires GSTIN + domain-specific compliance + a live privacy policy URL — these are server-side enforced. (planned: request-level sandbox tagging on individual MCP calls — not yet shipped.)

How fast is sandbox onboarding really?

Path B (manifest editor) is live now — typically 5-15 minutes per intent. Path A (paste MCP URL → auto-probe self-service) — the probe infrastructure is built but currently admin-only. The partner-facing self-service input is on the roadmap. (planned: Day 6+) Path C (custom integration) — depends on how fast your team ships code.

Next steps

  1. Read your target intent's spec — start with docs/intents/_INTENT_CATALOG.md
  2. Implement the tools per §3
  3. Return responses matching §4
  4. POST signed CPC webhook on close per §7
  5. Pass §11 sandbox-to-production checklist
  6. Get status: live
  7. Receive traffic, get paid 90% of amount_inr per closed intent

No phone calls. No human onboarding. The spec is the contract.

Reference docs

Built by AUTOMOBNXT · DPIIT Recognised Startup · 2026.

Get sandbox keys →

Built by AUTOMOBNXT · DPIIT Recognised Startup · 2026