Platform Adoption Guide

Choose Your Starting Point

Use this guide when a route, request, response, permission model, integration, or deployment behavior needs to be understood before people rely on it. In this guide, Platform Adoption Guide narrows that work to adopter documentation for partners-api services, access, adoption workflows, privacy, and support readiness. Because this is a start page, read it as part of the Platform adoption learning path rather than as an isolated checklist.

An API is a contract between systems. Even technical changes can affect attendee records, dashboard behavior, notifications, payments, files, or staff tools. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Section Helps You Decide

This is the map page. Start here when you know the general area but not the exact guide. The page should help you choose the next safe reading path before opening a dashboard screen, file, service route, or record. The intended readers are partner administrators, event leads, adoption leads, and integration owners. If the guide names a dashboard screen, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: partners-api.
• Records or contracts involved: API service expectations, Auth state, and Platform records.
• Main care point: Watch for using a service route with the wrong actor, changing a response another app depends on, leaking a secret, or triggering the same side effect twice.
• Proof worth keeping: route inventory, method and path, auth model, request and response shape, platform owner confirmation, test result, consumer note, and deployment evidence.

A Natural Way Through The Section

1. Name the situation in front of you: Begin by naming the Platform adoption situation, the owner, and the exact item involved in Platform Adoption Guide.
2. Match it to the closest guide group: Use partners-api to connect the words on the page to the screen, file, route, or service trail that people actually use.
3. Open one guide at a time: Keep API service expectations, Auth state, and Platform records in view so the work stays tied to the records or contracts it can affect.
4. Return here when the work changes shape: Before handing off, save proof such as route inventory, method and path, auth model, request and response shape, platform owner confirmation, test result, consumer note, and deployment evidence so an adoption lead and a non-specialist reviewer can understand what the route does and how it was verified.

Leave This Page With A Direction

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on callers, records, permissions, secrets, side effects, and downstream apps.
3. Proof is findable: The handoff points to evidence that an adoption lead and a non-specialist reviewer can understand what the route does and how it was verified.

End-to-end adoption runbook

1. Step 1 - Name the API workflow and owner: Identify the product area, organization owner, service path, and relying team before adopting a workflow or integration.
2. Step 2 - Read the contract in human terms: Check who can use it, what information is exchanged, what can fail, what records change, and what proof the adopting team must keep.
3. Step 3 - Prepare auth and input deliberately: Confirm the right role, account, partner, event, and approved data before depending on the workflow.
4. Step 4 - Use or request the route in the right environment: Use the approved dashboard, rego, LAN, or integration environment and keep credentials out of notes, screenshots, and exports.
5. Step 5 - Check returned data and real side effects: Confirm the visible result, affected records, external action, and review evidence in plain language.
6. Step 6 - Record tests, docs, and handoff notes: Record the owner, expected behavior, adoption evidence, and escalation path before relying on it in production.

What this section covers

The Platform adoption docs explain the services behind partner dashboards, attendee registration, EMS LAN, webhooks, external integrations, environment readiness, access rules, support evidence, and adoption handoffs.

Capability families

• Authentication: Dashboard auth, Supabase Auth hooks, access checks, session helpers, and permission discovery.
• Access and Core Data: Generic data access helpers, profile records, uploads, image proxying, SPA contracts, and guarded test-run utilities.
• Admin and Organization: Partner administration, organization settings, notices, Discord administration, and trust-safety enforcement records.
• Registration and Attendees: Attendee registration, profiles, fursonas, reservations, waitlist, group registration, and affiliate rewards.
• Event Management: Event configuration, conditions, activities, HR, communications, analytics, Dealers Den, check-in, inventory, and POS-adjacent operations.
• Finance and Payments: Payment providers, account records, finance programs, settlement records, refunds, transfers, and upgrades.
• Social and Integrations: Discord, Telegram, social account linking, state tokens, member tags, roles, and ZEP access.
• EMS LAN Support: Hosted LAN release proxy behavior and release download support.
• Webhooks and Contact: Public contact form, Auth hooks, and public waitlist entrypoints.

Action list

1. Action 1 - Start with foundations: Read What Is partners-api? before using a service route.
2. Action 2 - Find the capability family: Open the relevant capability reference page and verify service owner ownership.
3. Action 3 - Check the generated contract: Use Capability Route Inventory to find exact method, path, internal trace line, access note, and capability fields.
4. Action 4 - Confirm security: Review Permissions and Roles and Data Privacy and Auditability.
5. Action 5 - Adopt with proof: Follow Request a New Platform Capability or the product-specific workflow.
6. Action 6 - Keep adoption notes current: Ask the platform owner to refresh the capability inventory whenever platform behavior changes.

Current audit baseline

• Service areas scanned: 48
• Mounted capability families: 55
• Generated capability entries including aliases: 396
• Internal trace root: C:\Users\Workstation\Documents\Github\partners-api