# The public API

Every site-kit module talks to Sonor over one public API at `https://api.sonor.io/api/public`. site-kit is the supported way to use it: it handles auth, caching, the site host, retries and spam defense for you. This page is for when you need to know what's underneath.

## Authentication

Every request carries the project's key in the `x-api-key` header:

```bash
curl https://api.sonor.io/api/public/... \
  -H 'x-api-key: sonor_xxxxxxxx_xxxxx'
```

The key identifies the project, so a request never sends a project id. Keys look like `sonor_{first 8 characters of the project id}_{secret}`. A site sets one variable, `SONOR_API_KEY`, and `SiteKitLayout` passes the browser a short-lived credential for the calls that happen there.

## Multi-site projects

One Sonor project can serve many domains: a company site plus regional microsites, say. Reads and writes carry the site host (`?site=` on reads, a `site` field on writes) so each domain gets its own pages, forms and analytics. site-kit sends it automatically from `NEXT_PUBLIC_SITE_URL`.

## What's there

The API is grouped the way the site-kit modules are:

| Area                                            | site-kit module                                                                                                                         |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| SEO metadata, schema, FAQs, sitemaps, redirects | [SEO](https://sonor.dev/site-kit/seo), [Sitemap](https://sonor.dev/site-kit/sitemap), [Redirects](https://sonor.dev/site-kit/redirects) |
| Analytics events, page views and Web Vitals     | [Analytics](https://sonor.dev/site-kit/analytics)                                                                                       |
| Forms and submissions                           | [Forms](https://sonor.dev/site-kit/forms)                                                                                               |
| Articles                                        | [Articles](https://sonor.dev/site-kit/articles)                                                                                         |
| Reviews and testimonials                        | [Reputation](https://sonor.dev/site-kit/reputation)                                                                                     |
| Products, services, events and checkout         | [Commerce](https://sonor.dev/site-kit/commerce)                                                                                         |
| Booking availability                            | [Booking](https://sonor.dev/site-kit/booking)                                                                                           |
| Chat, popups and banners                        | [Website chat](https://sonor.dev/site-kit/chat)                                                                                         |
| llms.txt and answer-engine data                 | [llms.txt and AEO](https://sonor.dev/site-kit/llms)                                                                                     |
| Agent tool-call reports                         | [MCP and agent tools](https://sonor.dev/site-kit/mcp)                                                                                   |
| Listings and search                             | [re-site-kit](https://sonor.dev/re-site-kit)                                                                                            |
| Portfolio and case studies                      | [agency-site-kit](https://sonor.dev/agency-site-kit)                                                                                    |

## Forms go through site-kit

A form submission is only accepted with evidence that a real browser rendered the page it came from. `<ManagedForm>` and the headless `useForm` hook send that evidence automatically; a hand-rolled `fetch`, or a proxy through your own API route, can't. Sonor refuses those before anything is written, so the visitor sees an error and you get no lead.

So:

- Use `<ManagedForm>`, or `useForm` when the design needs its own markup.
- Define the form's fields in Sonor, so both can render and validate them.
- Send routing to different inboxes from Sonor (one form per destination), not from a proxy.
- For agents, turn on "Agent inquiries" for the form and use the MCP `send_inquiry` tool. See [Agents and AI visibility](https://sonor.dev/guides/agents).

## Using the API from something other than Next.js

site-kit targets Next.js 16. From another stack, the data reads (SEO, articles, reviews, llms data) work over plain HTTP with the key. Forms don't, for the reason above. If you're planning a non-Next integration, talk to us first at [sonor.io](https://sonor.io/contact).
