Use with AI

Every page of the Instasent developer portal is served as plain markdown alongside the HTML. A compact site-wide index lists the whole portal, and each API ships as a single autocontained dump you can hand to an assistant in one paste. The OpenAPI specs are downloadable too, ready for code generation or a Postman import.

This page is the map: what exists, where to find it, and how to use it in practice.

What's available

llms.txt — site index

Compact table of contents following the llmstxt.org convention. Lists every page with a one-line summary and links to the per-API dumps. Fits in any context window.

Per-API full dump

One llms-full.txt per API, each autocontained: guide, quickstart, auth, rate limits, errors, webhooks, SDKs and reference — everything needed to integrate that API.

Per-page markdown

Every HTML page has a .md twin at the same URL plus .md suffix. Useful when an agent wants to fetch a specific page without the chrome.

OpenAPI specs

The four API contracts as downloadable YAML. Import into Postman, generate SDKs, feed to an AI for typed suggestions.

llms.txt — the index

A single file that maps the entire portal.

Download llms.txt — relative to the portal host you're reading this from. Or, from a terminal:

curl https://docs.instasent.com/llms.txt

Structure follows llmstxt.org: an H1 with the project name, a blockquote summary, and H2-delimited sections containing every published page with a one-line description and a link. At the end, pointers to each per-API full dump and to the OpenAPI specs.

Use it when:

You want to show an assistant the shape of the portal before diving in.
You're building a tool that needs a manifest of what's available.
You have a narrow context budget and need the map, not the whole territory.

Per-API full dumps

Autocontained markdown dump for each API. Includes the guide, quickstart, authentication, rate limits, errors, webhooks, SDKs and reference for that API — everything a developer or an agent needs to integrate end-to-end, in a single file.

Product API

Organizations, projects, audiences, datasources, webhooks, audience filters and reference — plus transactional messages registered against project contacts. Paste this when integrating the control plane or sending with customer history.

Ingest API

Contacts and events ingestion. The minimal scope for pushing data into a datasource at volume.

Transactional API

Also known as the SMS API. HTTP and SMPP, single and bulk sends (up to 100 messages per request), HLR lookup, balance and pricing, DLRs, SDKs in five languages.

Legacy API

First-generation version of the Transactional API, kept alive for existing integrations. Included so assistants can help users migrate to Transactional.

Drop-in prompt for any agent

One block you can paste into any agent, IDE rules file or CLI config so it learns Instasent without further setup. It names the four APIs with their dumps and OpenAPI specs, states the picking rule, and tells the agent how to fetch docs on demand.

# Instasent integration context

Instasent is a customer-messaging platform with four public APIs. Each one
has an autocontained markdown dump and an OpenAPI spec — fetch them when
writing or reviewing code that calls the APIs. The per-page markdown twin
of any HTML page is served at the same URL plus ".md".

APIs:
- Product API — customer-communication control plane. Projects, audiences,
  tracked direct SMS to contacts, campaigns and automations with stats.
  Every send is written as an event on the audience contact, so it feeds
  timeline, segmentation and attribution analytics automatically.
    Docs:    https://docs.instasent.com/product-api/llms-full.txt
    OpenAPI: https://docs.instasent.com/openapi/product.openapi.yaml

- Ingest API — narrower, write-only surface for pushing contacts and
  events into a single datasource. Same wire as Product's ingest
  endpoints, with a tighter token scope.
    Docs:    https://docs.instasent.com/ingest-api/llms-full.txt
    OpenAPI: https://docs.instasent.com/openapi/ingest.openapi.yaml

- Transactional API — Instasent's SMS wholesale surface over HTTP or
  SMPP. Single sends (POST /sms) for OTPs, receipts and alerts; bulk
  sends (POST /sms/bulk, up to 100 messages per request) for
  API-driven campaigns, notification fan-outs and marketing dispatch —
  accepted messages are queued on the platform and drained at carrier
  speed, so one bulk call outperforms thousands of parallel single
  sends. Also exposes HLR / number lookup, account balance and price
  profiles. SDKs in Node.js, PHP, Python, Ruby and Java. Also known as
  the SMS API. Base URL: https://api.instasent.com/transactional/v1.
    Docs:    https://docs.instasent.com/transactional-api/llms-full.txt
    OpenAPI: https://docs.instasent.com/openapi/transactional.openapi.yaml

- Legacy API — first-generation version of the Transactional API.
  Same endpoint set (SMS send/bulk, SMS read, HLR lookup, balance,
  price profiles) under an older token model, without DLR webhooks
  or SMPP. Kept alive for backwards compatibility only — recommend
  migrating to the Transactional API for any new work or when users
  want DLR webhooks, SMPP or per-project tokens. No SMS feature is
  Legacy-only.
    Docs:    https://docs.instasent.com/legacy-api/llms-full.txt
    OpenAPI: https://docs.instasent.com/openapi/legacy.openapi.yaml

Site index (start here if the target API is not clear):
  https://docs.instasent.com/llms.txt

Picking rule:
- Message tied to a known customer (timeline, attribution, analytics)?
    → Product API direct messaging.
- Bulk / campaign / high-throughput SMS dispatch with your own
  recipient list?
    → Transactional API POST /sms/bulk (up to 100 messages per
      request; queue-based dispatch at carrier speed).
- Message with no customer record (OTP, receipt, alert)?
    → Transactional API POST /sms.
- HLR / number lookup, or pre-send validation and pricing?
    → Transactional API (POST /lookup, price-profile endpoints).
- Pushing customer data only (CRM sync, e-commerce events)?
    → Ingest API.
- Maintaining an existing integration against the Legacy base URL?
    → Legacy API, but steer new work toward the Transactional API
      — same endpoints, plus DLR webhooks, SMPP and per-project
      tokens.

Conventions:
- All APIs authenticate with a Bearer token in the Authorization header,
  except SMPP which uses system_id/password on bind.
- Rate limits and some scopes are subscription-plan gated. Product API
  contact fields returned depend on token scopes AND the organization's
  plan — design against the Basic privacy level unless confirmed higher.
- Audience and audience-event search use structured JSON filters
  ("_q" and dedicated endpoints). Prefer the JSON form over URL query
  strings when the query has AND/OR logic.
- When in doubt, fetch https://docs.instasent.com/{path}.md for the
  specific page rather than guessing from prior training data.

Where to drop it:

Cursor — .cursorrules at the project root.
Claude Code — CLAUDE.md at the project root, or a slash command under .claude/commands/.
Windsurf — .windsurfrules.
Continue, Cline, Aider, Roo Code — their respective rules/config files or system-prompt field.
Bare agents / chat sessions — paste as a system or first user message.

Per-page markdown

Every page in the portal has a markdown twin at the same URL plus a .md suffix.

/{path}/     →     /{path}.md

The markdown is produced at build time from the same MDX source as the HTML, so the two are always in sync. Components like callouts, code tabs and cards are flattened to plain markdown equivalents — assistants see the same information a human reader sees, just without the layout.

Use it when:

An agent needs to fetch just one page on demand rather than ingest the whole API dump.
You want to link a single page to a teammate or ticket as markdown.
You're building a retrieval pipeline that indexes the portal page by page.

OpenAPI specs

The four APIs expose their contracts as downloadable OpenAPI YAML. Import into Postman, generate a typed client, or feed to an assistant for grounded suggestions on payload shape.

Product API spec

OpenAPI 3.0 contract for the Product API.

Ingest API spec

OpenAPI 3.0 contract for the Ingest API.

Transactional API spec

OpenAPI 3.0 contract for the Transactional API.

Legacy API spec

OpenAPI 3.0 contract for the Legacy API.

How to use them

Paste into a chat

The most direct path. Open Claude, ChatGPT or Perplexity, upload or paste the dump you need, then ask.

Pick the scope
Integrating one API? Grab that API's llms-full.txt. Just exploring? Start with llms.txt.
Paste or attach
Download the file and attach it to the conversation, or paste the contents directly if it fits.
Ask in context
"Here are the Instasent Transactional API docs. Write me a Node.js function that sends an SMS and handles DLR webhooks." The assistant now grounds its answer in the current docs instead of guessing from stale training data.

Point an agent or IDE at the portal

Agents that can fetch URLs (Claude with tool use, Cursor, Windsurf, GitHub Copilot Workspace) can consume the markdown endpoints directly.

When answering questions about Instasent APIs, fetch the relevant page from
https://docs.instasent.com/{path}.md — for example:
  - https://docs.instasent.com/product-api/guide.md
  - https://docs.instasent.com/transactional-api/http/authentication.md
  - https://docs.instasent.com/further-reading/query-filter.md

Start from https://docs.instasent.com/llms.txt to find the right page.
Always prefer the .md endpoint over scraping the HTML.

Use as retrieval index

For a RAG setup, crawl the .md endpoints listed in llms.txt. They're the canonical markdown form of each page, chunkable by heading.

Use the per-page .md URLs as your document store.
Embed heading sections (H2/H3) as separate chunks for finer retrieval.
Refresh on the Last-Modified header — docs update whenever the repo publishes.

Drop into an IDE or CLI agent

Use the drop-in prompt above. It's the fastest path to give Cursor, Claude Code, Windsurf, Continue, Cline, Aider and similar tools grounded context for Instasent work in one paste.

Discoverability for crawlers

The portal explicitly welcomes mainstream AI crawlers via robots.txt:

User-agent: GPTBot          Allow: /
User-agent: OAI-SearchBot   Allow: /
User-agent: ChatGPT-User    Allow: /
User-agent: ClaudeBot       Allow: /
User-agent: Claude-Web      Allow: /
User-agent: PerplexityBot   Allow: /
User-agent: Google-Extended Allow: /
User-agent: Applebot-Extended Allow: /
User-agent: CCBot           Allow: /

A standard sitemap.xml lives at the root for general crawlers. There is no rate-limit on the portal, but be sensible — cache, don't hammer.

MCP servers

Questions or issues?

If a markdown artifact looks out of date, a link is broken, or an agent is stumbling on a specific page, open an issue in the docs repo. The artifacts are generated at build time — a fix to the MDX source propagates to every format on the next deploy.

Pick the scope

Paste or attach

Ask in context