Authentication

In Short

• Public pages — no authentication of any kind. Every marketing, blog, and glossary URL is open, in HTML or markdown.
• Widget API — authorized by the campaign's share_link UUID, a capability token carried in the URL path. Nothing else is required.
• Account data — reachable only through a signed-in browser session. There is no token-authenticated account API yet.

Widget API: the Share-Link Capability Token

The one public, programmable surface is the widget API under /api/widget/{share_link}/, specified in openapi.json. Every endpoint is scoped to a single campaign by its share_link — an unguessable UUID that acts as a capability token in the path:

curl https://attendir.com/api/widget/{share_link}/config

Possession of that UUID authorizes exactly the widget-level operations documented in the spec, for that one campaign, and nothing else. It ships inside the campaign's public embed snippet, so it is not a secret in the way a password is — but it is still the credential, so treat it like a bearer token scoped to one campaign, and rotate the campaign if it leaks somewhere you did not intend. You will find it in the Embed Widget section of the campaign page.

There are no headers to send: no Authorization, no keys, no scopes. Every endpoint is CORS-enabled and, except GET /email-html, rate-limited — responses carry X-RateLimit-Limit and X-RateLimit-Remaining, and exceeding a limit returns 429 as JSON.

One endpoint layers a second credential on top. POST /api/widget/{share_link}/linkedin/share publishes on a real attendee's behalf, so it additionally requires the short-lived, single-use widget_token that the LinkedIn OAuth popup issues to the widget; a missing, expired, or already-used token returns 401. That popup flow also validates the embedding page's origin against the campaign's allowed-domains list, so LinkedIn sharing from your own domain works once your origin is registered for the campaign — email info@attendir.com to have it added. Every other channel works on any site out of the box.

Signing In to the Product

The Attendir application authenticates people with a session cookie, established by email and password or by Google sign-in at /login. Accounts are self-serve: register, get a 7-day free trial with no credit card, no sales call, and no demo gate.

That session is the only way into account data today. Attendir issues no machine credentials for it — no service accounts, and no headless login flow — so an agent cannot obtain account access on its own. Anything that drives the product on a person's behalf drives their browser session.

What Attendir Does Not Have

Listed explicitly, because a wrong guess here costs an agent a wasted round trip:

• No OAuth 2.0 authorization server, and therefore no /.well-known/ OAuth metadata document. Publishing RFC 8414 or RFC 9728 metadata with nothing behind it would only mislead you.
• No API keys, client credentials, personal access tokens, or scopes — nothing to generate in the UI, because there is no surface that would consume it.
• No general-purpose account API for events, campaigns, advocates, or analytics. The widget API above is the whole public API.
• No SDK packages on npm or PyPI, no MCP server, and no agent card.
• No sandbox or test environment; there is one production environment, and a trial account is how you try things safely.

Some of these are on the roadmap. None of them are shipped, so none of them are advertised.

How Integrations Authenticate

These are credentials Attendir uses to reach other systems on your behalf, configured inside the product — not a way in to Attendir:

• Eventbrite — authorization-code OAuth 2.0, connected from your account
• Bizzabo and Cvent — OAuth 2.0 client credentials
• Luma — an API key you paste in
• LinkedIn — each attendee connects their own account through LinkedIn's OAuth consent screen; Attendir never holds attendee passwords

Requesting Programmatic Access

A scoped, token-authenticated account API is on the roadmap, and concrete use cases are what move it up. Email info@attendir.com with what you are building, which resources you need to read or write, and whether you are acting for one account or many.

Security contact and disclosure policy: /.well-known/security.txt (RFC 9116) and /security. Full developer reference: /docs.