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

# FAQ

> Answers about current connectors, destination tables, transformations, sync modes, and pipeline runs.

## Which connectors are live in the public docs?

PostgreSQL, MySQL, MongoDB, and Airtable are available as sources and destinations.
Asana, Notion, Strapi, HubSpot, and Stripe are available as sources. Asana exposes
eight supported streams, Notion discovers each shared data source dynamically,
Strapi accepts validated Content API IDs from each customer's Strapi 5 project,
Stripe exposes 34, and HubSpot exposes ten. MySQL, Airtable, Asana, Notion, and
Strapi are runtime-capability gated, so the connection picker shows them only
when both the API and ELT runtime report support for the selected role.
MongoDB is explicitly enabled as an Available Now connector after real MongoDB-to-
PostgreSQL, PostgreSQL-to-MongoDB, and MongoDB-to-MongoDB verification.

See [Connections Overview](/connections/overview) for the canonical availability table. Other connector pages remain as direct-link status notices and are not live self-serve workflows.

## Does Arcyria create destination tables?

The delivery runner does not create final tables. Create the destination table
before running, or use the explicit setup action when the selected database
destination exposes it. For Airtable, create the table and fields in Airtable,
then refresh destination discovery. The runner validates the final contract and
fails clearly when it is missing or mismatched.

MongoDB can create a collection on first write, but production deployments
should pre-create and review validators and unique indexes for the selected
Upsert keys.

## Where do I select source tables?

Open the pipeline **Source** tab. Click **Discover catalog**, enable streams in
the table, choose sync modes/cursors, use **Preview**, and click **Save stream
settings**.

## Where do I write SQL?

Open **Transformations**, select a destination, and create or open its
transformation editor. Save SQL as a draft, validate it, preview output, and
publish the revision.

Reference staged source data with the source helper:

```sql theme={"theme":{"light":"github-light","dark":"github-dark"}}
SELECT *
FROM {{ source('raw', 'public__orders') }}
```

## Where are rename and cast rules?

The former Normalisation panel is no longer part of the current workspace. Use
explicit SQL aliases and `CAST(...)` expressions in the destination-owned
transformation.

## Which write mode should I use?

Use **Upsert**. It is the live write mode in the current app.

If the destination table has a primary key, delivery uses merge behavior. If it has no primary key, delivery appends rows and records a no-primary-key warning.

## Can I schedule a Full Table sync?

Yes, schedules are pipeline-level controls in **Settings**. A scheduled Full
table stream rereads all visible rows, so review source size and API limits
before enabling it.

## Why did my run fail before writing rows?

See [Troubleshooting](/troubleshooting) for connection, discovery, validation, delivery, Incremental sync, and billing checks.

## Is staging data permanent?

No. Runs stage data in temporary storage. The runner extracts checkpoint state and cleans up the staging file during cleanup.