Get in Touch

Have a question about the platform, need help with your integration, or want to discuss partnership opportunities and enterprise pricing? Drop us an email — we’ll do our best to get back to you within 3–4 hours.

contact@fiwano.com
Documentation menu

Fiwano API Documentation

Built for people and AI agents

Every page here is human-readable — task guides and concepts — backed by a complete OpenAPI contract. The same reference is bundled in an open cookbook you can clone into your project in seconds.

Working with an AI agent? Clone the cookbook

Recommended

Point your agent at PLAYBOOK.md — a step-by-step guide to the API reference and working examples, so it reads only what each step needs.

View the cookbook on GitHub

Prefer to paste context instead? Download the full docs as one Markdown file, or grab just the raw spec.

Download .md Raw spec: openapi.json · openapi.yaml

Authentication

All API requests require an API key in the X-API-Key header. Clients that only support bearer tokens can send the same key as Authorization: Bearer YOUR_API_KEY; when both headers are present, X-API-Key is used.

Create a key from the API Keys page in the portal. The full key is shown only once — save it securely. Lost keys cannot be recovered; revoke and create a new one.

curl https://fiwano.com/api/v1/channels \
  -H "X-API-Key: YOUR_API_KEY"

All keys start with mip_live_. Keys are hashed on our side.

API keys are secret: call the API from your server or backend functions, never from client-side code. The API does not accept cross-origin browser (CORS) requests.

Compatibility

Fiwano has no version numbers. The API contract is v1 (https://fiwano.com/api/v1), and it has been stable since the public launch in March 2026. The service ships continuously; new capabilities are listed in the changelog (with an Atom feed).

Every change to v1 is additive:

  • new endpoints;
  • new optional request parameters and fields;
  • new fields in responses and webhook payloads;
  • new webhook event types and new values in open sets such as delivery statuses, error hints, and the inbound message type data.type (an unknown type is handled like unsupported).

What stays fixed: existing endpoints, field names, types and meanings; the X-API-Key authentication (Authorization: Bearer is an accepted alternative); the webhook signature scheme. New webhook event types are never enabled on your channels without your action — you opt in per channel via webhook_events.

What your integration needs to do to stay compatible: ignore fields it does not know and ignore event types it did not enable. Do not treat an unknown field or a new value in an open set as an error.

If a breaking change ever becomes unavoidable, it ships as a new API version alongside v1, announced in the changelog and by email in advance. v1 keeps working.