Build
SDKs and connectors
Build against the released HTTP contracts today and understand where native connectors fit.
There is no official client SDK yet
Use standard HTTPS clients and the public OpenAPI document. Do not depend on repository modules, internal packages, undocumented routes, or inferred provider adapters.
- curl is appropriate for setup checks and manual verification.
- Use fetch, Axios, or your platform's standard HTTP client in production.
- Generate a typed client only from /developers/openapi.json.
- Pin your generated client to a reviewed OpenAPI revision.
Choose native setup or middleware
A native connector lets the customer authorize and configure a known provider inside Concierge. CRM Webhook lets a developer adapt any CRM without changing Concierge's public contract.
| Path | Who configures it | Best for |
|---|---|---|
| Airtable native connector | Customer | A selected Airtable base and table |
| CRM Webhook | Customer + developer | Any CRM reachable through secure middleware |
| Routing webhook | Customer + developer | Alerts, automations, and team notification systems |
| Ticket API | Customer + developer | External ticket and service-request tools |
Production connector checklist
Treat every installation as an independent customer boundary even when your middleware serves many customers.
- 1Store credentials per installation and environment.
- 2Validate installation, account, site, and external-record relationships.
- 3Use idempotency for creates and atomic replay protection for signed deliveries.
- 4Map only fields approved by the customer.
- 5Expose health, accepted, rejected, and last-success evidence without logging secrets.
- 6Test one customer, two sites, and two separate customer accounts before general availability.
Next guide
API reference