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

# Environments

> Daysync currently operates a single production environment. Here's how to develop safely.

Daysync currently runs **production only**. There is no public sandbox. This page explains how to develop and test against production without affecting real tour data.

## Endpoints

```text theme={null}
API:          https://integration.daysync.com
OAuth:        https://integrations.daysync.com
Daysync app:  https://app.daysync.com
```

The same URLs serve every partner. Your `x-api-key` / `x-api-secret` are unique to your app and double as your OAuth client credentials — there is no shared OAuth client (see [Authentication](/authentication)).

<Note>
  The two API-side hosts differ by a single letter: OAuth authorize/token lives on the **portal** `integrations.daysync.com` (plural), and the data API is `integration.daysync.com` (singular).
</Note>

## Safe-development pattern

Use the `is_demo` flag and a dedicated test organization to keep your work isolated from real customer data.

<Steps>
  <Step title="Create or pick a trial/beta organization for testing">
    Subscription gates (HTTP `402 SUBSCRIPTION_REQUIRED`) don't apply inside `trial`, `beta`, or `unlimited-free` organizations. Have a Daysync team member set yours up if you don't have one.
  </Step>

  <Step title="Create tours with is_demo: true">
    ```bash theme={null}
    curl -X POST https://integration.daysync.com/v1/tours \
      -H "x-api-key: dk_live_…" \
      -H "x-api-secret: ds_…" \
      -H "Authorization: Bearer eyJraWQ…" \
      -H "Content-Type: application/json" \
      -d '{
        "name": "Integration Test 2026-06-12",
        "org_id": "<test-org-uuid>",
        "start_date": "2026-07-01",
        "end_date": "2026-07-05",
        "timeZone": "Australia/Sydney",
        "is_demo": true,
        "days": [
          { "day_type_id": 1, "name": "Day 1", "formatted_address": "Sydney", "date": "2026-07-01" }
        ]
      }'
    ```

    Demo tours are flagged in the Daysync UI, so they're easy to identify and clean up later.
  </Step>

  <Step title="Clean up with soft-delete">
    ```bash theme={null}
    curl -X DELETE https://integration.daysync.com/v1/tours/<tourId> \
      -H "x-api-key: dk_live_…" \
      -H "x-api-secret: ds_…" \
      -H "Authorization: Bearer eyJraWQ…"
    ```

    Soft-deleted tours are excluded from list endpoints and return `404 TOUR_NOT_FOUND` on direct access.
  </Step>
</Steps>

## Local development

For local development, your callback URL is typically `http://localhost:<port>/oauth/daysync/callback`. Add it yourself under **Redirect URIs** on your app in the portal — localhost may use `http` — see [Callback URLs](/callback-urls).

<Tip>
  Cache the access token and refresh token in your local development store the first time you complete the OAuth flow. Otherwise you'll re-authorize every hour while iterating.
</Tip>

## Why no separate sandbox?

Daysync's data model is tightly coupled to real organizations, subscription status, and tour membership — a sandbox with realistic behavior would require shadow-copying significant production state. For partner volume to date, the `is_demo` + trial-org pattern has been sufficient.

If your security review or compliance posture requires isolated testing, contact `support@daysync.com` to discuss a dedicated test tenant.