Connect overview
The building blocks of Nexra Connect (connections, integrations, flows, deployments and runs) and how data moves safely between systems.
Updated 07/10/2026
Building blocks
| Object | What it is |
|---|---|
| Connector | Nexra's adapter for one provider, for example Xero, Shopify or Snowflake. Each connector publishes its operations, such as invoices.list or orders.create. Browse them in the connector directory. |
| Connection | Your authenticated link to one provider account, in one environment. It holds the provider settings, a Key Vault reference to the credentials and the write operations you allowed. |
| Integration | A business process inside a project, such as "Order to cash". It owns flows and deployment environments. |
| Flow | Steps joined by edges: a trigger, a source operation, map, transform, filter and validate steps, and a destination operation. Flows are versioned; published versions are immutable. |
| Environment and deployment | Where a published flow version runs (development, test, staging or production) and the approval that let it run there. |
| Execution (run) | One run of a flow, with its steps, records, errors and recovery options. |
Operations
Every connector operation has a key in the form <entity>.<action>: for example customers.list, invoices.get or orders.create.
Reads (list, get, search) can be flow sources. Many support incremental sync with an updatedSince input.
Writes (create, update, upsert, send, generate) can only be flow destinations. They are refused unless the connection explicitly allows them, and they require approval before production use.
Each write declares its duplicate protection:
| Idempotency | Meaning |
|---|---|
| Native idempotency key | The provider honours an idempotency header that Nexra derives from the run and record. Retries are safe. |
| Natural key | The write targets a record by its ID or unique key, so repeating it updates the same record. |
| Not retried automatically | The provider offers no duplicate protection. Nexra never retries an uncertain write; the record goes to the dead-letter queue for a person to review. |
| Billable | The write costs money at the provider (for example buying a shipping label or running warehouse compute). It is never retried. |
Safety model
Credentials never leave Key Vault. Connections store a secret reference, and fields that look like secrets are rejected from settings.
Fixed destinations. Each connector only calls its documented provider origin; foreign hosts, private networks and redirects are refused.
Explicit writes. A connection can only perform the write operations you ticked.
Separation of duties. Production deployments and sensitive actions need approval from a different workspace member.
Bounded retries. Rate limits and provider errors are retried with backoff (up to three attempts, honouring Retry-After). Writes without duplicate protection, and billable writes, are never retried.
No destructive defaults. Connectors do not delete records, refund, void, cancel, pay out or broadcast messages.
How much is validated
Each connector shows its validation level:
Fixture tested: the adapter passes Nexra's conformance suite against provider-shaped fixtures for every operation, including pagination, authentication failures, rate limits and write gating.
Provider sandbox validated: also exercised against the provider's own sandbox.
Authorised account validated: also exercised against a real, authorised customer account.
The directory reports how many connectors sit at each level. Validate a connection in your own sandbox before relying on it in production.