These Docs were reconciled against the production product on 9 August 2026. They describe organiser, attendee, event-day and public integration behaviour without exposing private infrastructure, provider secrets or internal architecture.
Accounts and pages are views of authoritative event, ticket and financial state rather than separate copies of the same event.
A valid session identifies an account. Role, event permission and fresh security checks determine which records and mutations are allowed.
Responsive design does not mean every dense desktop workflow is compressed into a phone.
Published status alone does not guarantee public visibility, checkout availability or financial readiness.
Venue identity, exact coordinates and arrival guidance have different visibility and validation rules.
Availability is server-confirmed and ticket design can inherit from the event or be overridden per ticket type.
Audience communication is permissioned, event-scoped and tied to supported triggers.
A discount, an event promoter and an organiser-acquisition partner can all support growth without sharing one permission or earning model.
Temporary connectivity loss should not force the queue to stop, but offline admission does not make every mutation offline-capable.
The account view compares events while a selected event unlocks detailed velocity and outcome views.
Attendee-facing values, provider totals, fees, refunds, commissions and payout allocation must not be collapsed into one number.
Ticket state, planning, notifications and post-event activity can continue changing after purchase.
The configured API origin for this deployment is https://eventos-api-staging.up.railway.app. Public integration contracts use the versioned /v1 namespace where available.
curl --request GET \
--url https://eventos-api-staging.up.railway.app/v1/me/capabilities \
--header "Authorization: Bearer YOUR_EVENTOS_API_KEY" \
--header "Accept: application/json" \
--header "X-Request-Id: docs-capabilities-001"const response = await fetch("https://eventos-api-staging.up.railway.app/v1/events?status=published&limit=20", {
headers: {
Authorization: "Bearer " + process.env.EVENTOS_API_KEY,
Accept: "application/json",
"X-Request-Id": crypto.randomUUID(),
},
});
if (!response.ok) {
const failure = await response.json().catch(() => null);
throw new Error(failure?.error?.message ?? "EventOS request failed");
}
const page = await response.json();
console.log(page.events, page.next_cursor);Exact surface and scope depend on credential and entitlement. Clients should preserve server-authoritative availability, currency, visibility and ticket state.
Networks can fail after a server has accepted a request. A caller must distinguish retrying one logical action from creating another.
An explicitly rejected credential and a failed network request have different recovery semantics.
Webhook receivers should assume retries and occasional out-of-order arrival are normal distributed-system behaviour.
import crypto from "node:crypto";
function verifyEventOSWebhook(rawBody, receivedSignature, secret) {
const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
const expectedBytes = Buffer.from(expected, "utf8");
const receivedBytes = Buffer.from(receivedSignature ?? "", "utf8");
return expectedBytes.length === receivedBytes.length &&
crypto.timingSafeEqual(expectedBytes, receivedBytes);
}Automation can perform allowed actions. It does not bypass organiser permissions, plan entitlements, event rules or attendee privacy.
EventOS combines account authentication, role checks, event access, ticket eligibility, scoped staff sessions and fresh MFA for different risk classes.
If a capability is desktop-first, trigger-limited or not publicly integrated, clients should not infer a hidden equivalent.