> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casa-layer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OAuth provider redirect callback

> Public endpoint the OAuth provider redirects to with `code` and `state`. Verifies signed state, exchanges the code, persists credentials, and redirects to the SPA. No bearer auth.




## OpenAPI

````yaml /api-reference/openapi.yaml get /v1/oauth/callback
openapi: 3.1.0
info:
  title: Casa API
  version: 1.0.0
  description: >
    Headless, read-only access to the guest context layer — the entire canonical
    data model over HTTP.


    Every endpoint is **scoped by the credential**: the default scope is the
    caller's property group, returning data across all of its properties. Auth
    sources resolve to the same credential: a user-generated **API key**
    (`casa_…`, created in Account settings — the recommended method for
    machines), a WorkOS AuthKit session JWT (the web app; org and role come from
    verified token claims), or a static token. (The MCP server also accepts
    read-only OAuth connector tokens, but those are rejected on these REST
    routes.) Send `X-Property-Id` to drill down into a single property; API keys
    can also be pinned to one property at creation. Tenant isolation holds by
    construction.


    Integration-management endpoints write connection *metadata* only and are
    session-only; canonical guest data enters exclusively through the connector
    workers and the ingest pipeline.


    The Model Context Protocol (MCP) server is exposed separately at `/mcp` and
    is documented under **MCP Server** in the guides — it is not a REST endpoint
    and is intentionally omitted from this reference. It accepts the same API
    keys.
servers:
  - url: https://api.casa-layer.com
    description: Production Cloudflare Worker
security:
  - bearerAuth: []
tags:
  - name: System
    description: Liveness, health, and the public welcome page.
  - name: Guests
    description: Canonical guest profiles as ingested from each source system.
  - name: Master Profiles
    description: >-
      Identity-resolved golden records — one entity per real guest, merged
      across sources and properties.
  - name: Reservations
    description: >-
      Reservation records linked to guest profiles, searchable by status, stay
      window, and channel.
  - name: Transactions
    description: >-
      Revenue lines (Pace Transactions V2–shaped) linked to guests and
      optionally reservations.
  - name: Consents
    description: >
      Contact-grain consent observations (contact method + value × purpose).
      Rows store decisive signals only (granted/withdrawn/denied); absence of a
      row means unknown / not eligible. Effective eligibility within a property
      group is the most restrictive status among stored observations for the
      same contact×purpose (withdrawn/denied beat granted).
  - name: Tables
    description: >
      Attio-style ops tables — curated or filter-defined containers for
      day-to-day work inside Casa. Tables are not consent eligibility records
      and not marketing segments; campaign audiences stay in downstream ESP
      tools (Klaviyo, Mailchimp, and peers).
  - name: Actions
    description: Guest actions (purchases, visits, and other tracked events).
  - name: Events
    description: >-
      The append-only guest event log — full change history or latest delta
      slice per entity.
  - name: Reviews
    description: Guest reviews with free-text search and an aggregate summary.
  - name: Loyalty
    description: Loyalty programs and member search (tier, points, guest).
  - name: Dimensions
    description: Reference dimensions — booking channels and bookable spaces.
  - name: Properties
    description: >-
      Properties within a group, plus self-serve onboarding (org-anchored tenant
      bootstrap).
  - name: SQL
    description: >-
      Read-only SQL over the public data model, isolated per tenant by row-level
      security.
  - name: API Keys
    description: Manage the organization's API keys (session-only).
  - name: Integrations
    description: >-
      Connection metadata for source systems (Mews, Square, …). Metadata only —
      never canonical guest data. Session-only.
paths:
  /v1/oauth/callback:
    get:
      tags:
        - Integrations
      summary: OAuth provider redirect callback
      description: >
        Public endpoint the OAuth provider redirects to with `code` and `state`.
        Verifies signed state, exchanges the code, persists credentials, and
        redirects to the SPA. No bearer auth.
      parameters:
        - name: code
          in: query
          required: true
          schema:
            type: string
        - name: state
          in: query
          required: true
          schema:
            type: string
      responses:
        '302':
          description: >-
            Redirect to the SPA integrations page (`oauth=success` or
            `oauth=error`).
        '400':
          description: Missing or invalid OAuth parameters or state.
        '503':
          description: OAuth is not configured on this deployment.
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: >
        `Authorization: Bearer <token>`. Token types resolve to the same scoped
        credential: a user-generated **API key** (`casa_…`, from Account
        settings — recommended for machines and MCP clients), a WorkOS AuthKit
        session JWT (the web app; org and role come from verified token claims),
        or a static token. API keys are group-scoped, optionally pinned to one
        property at creation. MCP OAuth connector tokens authenticate the MCP
        server only and are rejected on these REST routes.

````